and I haven't been able to find any discussion of the pros and cons of these. Signing the backups complicates making backups since it requires access to a secret key, and I'm not clear on what it buys you.

At a high level, do you understand the differences between signing and encrypting?

In general you don't want to use the same key for encryption and signing as you often want to be able to give the encryption key to someone else (say your spouse. Or in workplace environments your boss) while you wouldn't want to allow either of those groups to impersonated you (i.e. the signing key). There are also some theorical attacks that uses information leaked up by signing to attack the encryption. Not sure if actually helps in the real world as I don't follow it that closely.

Is it worth signing backups? For cases where you share your encryption key I could see value. For the rest of the use cases you might be crossing over into paranoid land.

I think I understand the difference between encrypting and signing, and if you're going to sign it makes sense to use a different key pair. I have some cloud space available to me on Google Drive and with a local ISP, and storing backups seems an obvious use, but if either of these is ever hacked I'd rather not have the bad guys be able to read my backups: hence the encryption. The point of signing seems to be to keep them from modifying the backups, and that's where I get lost. How could they modify the backups if they can't read them, and what would they hope to gain in any case? My imagination fails me.*

* also my Google skills. I keep finding articles about football players.

Cryptographically signing is similar to a physical signature. It is a way to say that you made something and only you could have made it.

To sign, you generate a hash from a document (such as your backup - either plaintext or encrypted) and then encrypt the hash with your private key. Somebody else can verify that you signed by using your public key to decrypt your encrypted hash and comparing that against their own calculated hash. If they match then only you could have signed it.

It's only of value if you want to share the backups and have the other person really know that they came from you. Not that useful in a scenario that involves you and a close circle (e.g. family).

Encryption: Your public key can make a file such that your private key and only your private key can decrypt it.

Signing: Your private key can make a signature such that anyone with your public key can verify it.

Public Key: This is a key that you mean to spread far and wide. Everyone who might send you a message should have it. Everyone who might receive a file/message from you should have it (to verify you actually sent it). There are even directories of public keys that people publish to in order to make it easier for folks o find the keys and make it slightly harder for hackers to impersonate them.

Private Key: The key that is just for you. In many cases, cybersecurity folks will be absolutely fanatical about this. No emailing or uploading ANYWHERE. Transfers ideally by moving USB keys around.

So, with that in mind. Here are the alternatives:

1) No Signing - Remember that anyone with your public key can encrypt files (they just can't decrypt afterward). So, let's say that I hack Google and identify that what is in your Drive is a Duplicity backup. If I can find your public key somewhere (and typically, public keys would be widely published) then, I could create a Duplicity backup file, then encrypt it with your public key. Remember that the underlying idea of public key cryptography is that everyone can encrypt messages/files to you, but only you can decrypt them. So, with this modified Duplicity backup file, the next time you restore from backup, you would merrily decrypt the file I put there and load it into your system. Now, I wouldn't have any way of knowing what files you had backed up, so you would notice that something is fishy pretty quickly. However, I don't need the illusion to last long: if I can successfully guess what OS you use at home, then I can create a login screen that looks close enough to normal that you might be induced to enter your login credentials. Except that rather than actually logging you in, it sends your credentials to me, which I can use with various online services to see whether you ever reused your password. Even if this scenario sounds far fetched, suffice to say: cybersecurity folks go apoplectic when it comes to any possibility that a hacker can cause their victim to boot into a hacked OS, for a whole variety of reasons.

2) Same Key - Well, let's fix this hole. You already have a public key and private key. Why not just use that key to sign the backup? If this is your everyday workstation, presumably, you would have your private key handy on it, so might as well use it. This prevents a hacker from injecting a backup file into a restore operation, because the hacker won't have access to your private key, so won't be able to sign it in a manner that would be verified by your public key. As a result, Duplicity would reject an attempt to restore from that backup and warn you that someone other than you created the file.

3) Now, rather than my personal workstation, let's assume I am an admin of 100 web servers. Even better, let's assume that I am a web host, so there are literally 10,000s of people of varying technical abilities crawling around doing who knows what. In such an environment, hacking of the servers is more of a 'how often' rather than an 'if'. So, you really, really, don't want to keep your main private key on these servers. Hey, no problem. Give each server your main public key for encrypting the backups, but not the private key (remember, the backup can still work, because anyone can encrypt with your public key, the private key is only required for decrypting). But now, the servers can't sign the backups, because they don't have your private key. So, have each server generate its own public/private keys for signing its backups. You'll need copies of each server's public keys, but you don't actually need a copy of their private key. This is convenient because securely storing private keys is much more of a pain than storing a public key (because you have to keep the private key, you know, private). So what happens? When you backup, the server uses your main public key to encrypt the backup, it also signs the backup with its own private key. If the server dies, you would download the backup to your local workstation, then use the server's public key to verify that the backup file had not been tampered with. Then you would use your main private key to decrypt the backup and load it into a new server. The old server's private key may well be lost forever, but that is no major loss. Have the new server generate a new key pair for signing backups and grab a copy of the public key, and you are good to go.

In terms of real advice: As an individual, hacking you is likely worth a shockingly little amount of money. While a hacker could rifle through some files looking for anything that looks like a CC or SSN, they are very unlikely to go for a full blown injection of a trojan into a backup file. So, my advice is this:

If you are going to keep your private key on the machine that is being backed up: Might as well sign the backup, for what little good it would do.

If you are going to keep your private key off the machine (say, on a different machine or on a USB key): Don't bother with signing. The risk seems sufficiently small relatively to how juicy of a target you are.

Using public key encryption when there is only one person who should access the data is a strange choice.

AFAICT it would be better to use a symmetric key cypher and keep the key private. This servers both to sign and to secure the data because the key is needed to either read or write the data. Symmetric key cyphers are faster and suspected to be stronger than public key cyphers.

Using public key encryption when there is only one person who should access the data is a strange choice.

AFAICT it would be better to use a symmetric key cypher and keep the key private. This servers both to sign and to secure the data because the key is needed to either read or write the data. Symmetric key cyphers are faster and suspected to be stronger than public key cyphers.

I agree with this. For encrypting data you are securing for your personal use only, don't use public key encryption - not necessary.

I think a better distinction is symmetric key encryption (same key encrypts and decrypts) vs asymmetric key encryption (different keys encrypt and decrypt). Assymetric key cryptosystems have the option of making one key public, but you do not have to do so.

In this case, the public (asymmetric) key encryption is more secure than a single symmetric key. You are using the encryption key every time you do a backup, but hopefully only need to restore from backup rarely. This means that the encryption key is much more likely than the decryption to be compromised accidentally or maliciously. If the encryption key is compromised, the backups are still secure if asymmetric/public key encryption is used since the decryption key remains private (assuming the entire backup process is not compromised).

If you sign the backups with the same key pair as used for encryption, then since signing is done with the private key, the private (decryption) key would be used every time the public key was used neutralizing the benefit of asymmetric keys over symmetric keys described in the previous paragraph. Thus it is preferred to sign with a different key pair but this leads to more administrative overhead.

Not signing the backup at all means that if your public/encryption key we’re ever compromised, while that would not be sufficient to decrypt your backups, it would enable someone to replace a backup with some other content encrypted with your public/encryption key wherein it would happily restore when you decrypt with the private/decryption key. This would be a pathway to restoring malicious content.

Thus, encrypting with one key pair and signing with another key pair would be the most secure option.

In this case, the public (asymmetric) key encryption is more secure than a single symmetric key.
...
Thus, encrypting with one key pair and signing with another key pair would be the most secure option.

AES 256 is quantum computing resistant, current practical public key systems are not.

AES 256 needs 256 bits of random numbers to select the key. Public key needs a lot more bits of random to select the key and yet more random bits during each encoding. Public key systems have fallen to attacks on bad random number generator. I can avoid this attack on AES using a deck of cards or boggle dice set. That's not so easy with public key.

There are others. The extra utility of public key comes with extra complexity and complexity is potential weakness.

Once a backup is stored in the cloud with a symmetric key, key compromise must be avoided for as long it is important for the data not to be compromised. Most successful attacks on protocols involving cryptography attack a weakness in the protocol leading to key compromise.

But regardless of point of view on that, it is a moot point because symmetric key encryption was not one of the choices.

Last edited by jalbert on Wed Jan 24, 2018 12:01 am, edited 1 time in total.

Thanks to everyone commenting. The tutorials I've looked at use asymmetric encryption and signing but don't explain the reasoning behind this choice, so the discussion here is very helpful. On further examination I see that symmetric encryption is also an option, but a somewhat mysterious one. From the man page for duplicity:

a Note on Symmetric Encryption and Signing
Signing and symmetrically encrypt at the same time with the gpg binary
on the command line, as used within duplicity, is a specifically
challenging issue. Tests showed that the following combinations proved
working.
1. Setup gpg-agent properly. Use the option --use-agent and enter both
passphrases (symmetric and sign key) in the gpg-agent?s dialog.
2. Use a PASSPHRASE for symmetric encryption of your choice but the
signing key has an empty passphrase.
3. The used PASSPHRASE for symmetric encryption and the passphrase of
the signing key are identical.