Cannot use separate signing and encryption keys with no secret encryption...
Brought to you by:
edso
Menu
▾
▴
#126 Cannot use separate signing and encryption keys with no secret encryption key without disabling GPG tests
Hello,
I am using separate PGP keys for signing and encryption, and the host backing itself up does not have the secret part of the encryption key. This configuration has been working fine for years, but I just upgraded from duply 2.1 to duply 2.3.1, and now I get the error "None of the configured keys 'xxxxxxx' has a secret key in the keychain. Decryption will be impossible!"
I can work around this by setting GPG_TEST='disabled' but it would be nice not to have to disable all the other tests just to using this particular configuration.
Thanks.
hey Sean,
this test was added intentionally, as recent duplicity since quite a while needs a a way to decrypt the backup on resume or archive-dir resync.
backups w/o secret key used to work in the past, but this was inherently flawed as it simply silently skipped syncing the local archive-dir if it detected a difference.
there is no security advantage of the local machine not able to decrypt data it encrypted in the first place. if you do not want to place your personal secret key on the box simply encrypt against your key and the machine key (being the signing key) and you are set.
hope that helps.. ede
Hello, thank you for the reply and the info! I think that duplicity will just restart a backup if it can't resume because it doesn't have the key to decrypt, right? I'm happy with that, and also don't mind restoring the metadata manually if necessary.
Just to note, there is the security advantage that old versions of files, or deleted files, can't be recovered from backups by an attacker.
no, it'll throw an 'cannot decrypt' error. that's why the precondition testing was added.
that may be. and duplicity actually does not need the volumes but the metadata only. still, it is implemented as it is now, feel free to offer a patch on duplicity's gitlab if you feel this is an important issue ;)
will close this now as 'wont-fix'.. sunny regards ede/duply.net
Okay cool, thank you for taking the time to fill me in.
Given this move away from using separate signing and encryption keys where the host doesn't have the secret encryption key, is there any point in using PGP keys at all as opposed to just using symmetric encryption with GPG_PW? I thought that the whole point of using keypairs was that the host wouldn't have both parts of the pair.
actually it is no move away from anything, but an acknowlegdement of the fact that creating something based on something encrypted (incrementals) needs a way to decrypt it.
duplicity mitigates this by keeping the unencrypted metadata in archive-dir. but should this data get out of sync for some reason or a backup interrupted/resumed duplicity will need to decrypt the remote.
you can still use different keys for signing and for encryption multiple even
getting a hold of a key is more difficult than just capturing a passphrase.
indeed. that's why you can encrypt against your private public key safely on the backup machine, keeping the secret key somewhere else enabling you to decrypt even if the machine key pair is getting lost for some reason.
please just use a 'machine/personal' two key approach. the the backup box can modify your remote storage, access your data, create new and maye older looking backups. if you don't trust your own machine, your setup is flawed anyway.
good luck.. ede
Last edit: ede 2021-08-17
Ah, so what you are suggesting is actually to encrypt to both my personal key and the machine's private key?
actually pgp encryption always only needs the public part of a key! but yeah, just encrypt against your public and the machines public key. keep your private key somewhere safe and be content to have second key able to unlock your backups.
..ede