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.
It's similar to this
issue. I'm thinking there should be some safe way to handle passphrase changes, but the added complexity is just not worth the effort up and down the chain.
For now, I will leave it alone.
...Thanks,
...Ken