[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] decryption failure in duplicity replicate

From: edgar . soldin
Subject: Re: [Duplicity-talk] decryption failure in duplicity replicate
Date: Tue, 24 Aug 2021 18:30:38 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1

On 24.08.2021 17:55, Kenneth Loafman wrote:
>     >I'm thinking we should add it back in again, but instead of testing it 
> by decrypting a file, we should just hash the original and store it in the 
> cache for later comparison.  We could use a strong hash like sha512 and 
> strong permissions on the file.
>     does feel quirky. we should never do anything with user secrets!
>     how about an encrypted but small file, specific to the full which must be 
> decryptable before doing incrementals? obviously it must never contain the 
> same value to protect encryption. or reuse the full's manifest and keep it 
> encrypted locally too, to check encryption against.
> Still would have to have a cleartext available for comparison and that would 
> weaken the encryption.

do we? wouldn't gpg decrypting it without complaining be enough?

> I like the hash approach as it's nonreversible. It's no weaker than the 
> /etc/passwd file, so should be acceptable.

only as strong as the hash and hashes tend to collide at some point. so why 
start there?

also - we are asking the wrong question. for something working for keys (assume 
multiple or passphrase of key changed inbetween) _and_ symmetric encryption
we don't wanna know
 "Is the passphrase still the same?"
but instead
 "Can we still decrypt with the settings given?" and as it is possible to 
switch/add keys between backups, we would actually wanna know if we can still 
decrypt _all_ manifests (backups) of the current chain.

if you think about it, it get's quite complex. so maybe we should leave it 
alone and treat it as a user error which it definitely is! if not i feel that 
decrypting all manifests or some small file per backup before incrementing 
would be the way to go.

just my 2cents :).. ede/duply.net

reply via email to

[Prev in Thread] Current Thread [Next in Thread]