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

[edgar . soldin]

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