Asymmetric encryption

[mclei-asw]

Feature request: is it possible to add asymmetric key encryption? Especially with multiple keys. It is widely used in Bacula to secure the backup volumes from accessing by backup server itself. Typical usage is to have 2 keys:

• server key - unique for backuped server. The private key could stay on server to be able to do restores, but is not necessary.
• master key - the same public key is on all servers. Private key is securely stored offline. Private key is used only in situation, the server's certificate is lost, to recover any backup.

I am really missing this feature in burp as it is now essential to save password from EVERY server and when you forgot one and lose the whole server, it is not possible to recover it.

[grke]

Hello,

It probably is possible. However, it is very non-trivial, and not particularly fun, so I probably wouldn't implement it without somebody paying me.

It would need lots of extra code being added, because it cannot be plugged into much of the existing encryption code. Do you know what sort of encryption that bacula uses for this?

[mclei-asw]

I understand this and we would like to sponsor the improvement of encryption support. We are now deciding how to change our backup encryption strategy as loosing deltas is a bit disadvantage.

For me there are 2 other problems with current encryption support:

• it is self-made encryption inside burp, without any security audit
• it is not possible to decrypt encrypted backup without burp

Is there any chance how to use some external encryption software? I understand that it would be very inefficient to launch external encryption software for every single file as is handling backup file by file. Does anybody know any better solution?

[grke]

Hello,

As far as I know, bacula does not call external encryption software, it uses the openssl library to do it. And that is the same as what burp does. The only difference is that the openssl functions that bacula calls are asymmetric ones, whereas burp calls symmetric ones. It is very possible to decrypt burp encrypted files without burp. You just need to call the right openssl functions.

[grke]

Not much more to be said. Closing.

[bittner]

However, it is very non-trivial, and not particularly fun

I don't see why in general this should be particularly difficult. When we do it "the right way":tm: then there should be something like a method get_encryption_password() that returns the symmetric password for the encryption. This should be in place today, this way or another.

For asymmetric encryption we "only" need to override the behavior of that method, which would do:

1. symmetric password available? -> yes, return it
2. create and exchange a symmetric password
3. cache the symmetric password and return it

Is there maybe a library that can already handle items 2 and 3 for us?

[grke]

I don't understand your points 2 to 3.

a) Are you describing the symmetric behaviour as you imagine that it currently works? b) Or are you trying to describe how you would implement non-symmetric behaviour?

It cannot be (a), because it currently works and therefore another library isn't needed. It cannot be (b), because you are still talking about symmetric behaviour.

[bittner]

I'm try to describe how easy it could be to implement encryption based on asymmetric keys. When you use the key pair to just exchange a symmetric key everything should stay the same in the current implementation. The only complexity that needs to be added is the generation and exchange of the encryption key.

It would need lots of extra code being added, because it cannot be plugged into much of the existing encryption code.

With the approach described above this would not need to hold true.

[grke]

I think I understand what you are saying. Use asymmetric keys to generate a symmetric key, and then use that symmetric key from that point onwards.

Unfortunately, I don't think that this (generating a symmetric key using symmetric keys) is what was requested.

What is wanted is the ability to use public keys to decrypt something that was encrypted with a private key.

[mclei-asw]

I think that YES. Asymmetric encryption is just about generating random SYMMETRIC keys for data encryption and then also encrypting this SYMMETRIC key by asymmetric keys.

So the primary code for backup encryption remains the same, just the key management should be added.

The is only one question. It does not make sense to use unique symmetric encryption key for each file in backup for speed penalty of asymmetric ciphers. So the whole backup should be encrypted using the same key. But the different backup files are then mixed on server side when combining backups. So the encrypted symmetric keys should be added to every file or some system of keys reference must be established.

[grke]

OK, thanks for explaining what I didn't understand.

I guess one way to do it would be to back everything up again as if every file were new if the generated symmetric key had to change since the previous backup. Then every file in a backup would have one symmetric key.

Re-opening, as it seems more achievable than I originally thought.

[mclei-asw]

Sorry but no. You do not understand it right. Symmetric keys is generated every backup operation, as you are storing it directly only in memory while backup is running. Then the key is encrypted by asymmetric cipher and you need just public key for this operation. And without private key you have no option to decrypt it on next backup run. So every backup, different symmetric key is used.

[grke]

I think we are talking about different things in the last two messages.

I was talking about the complete set of files in a single backup needing to be decrypted by a single key.

If you have backup 1 and 2, and 2 only contains the files that changed since backup 1, and reuses the same files that stayed the same since backup 1, then you need to keep track of which file needs which key.

[mclei-asw]

If you have backup 1 and 2, and 2 only contains the files that changed since backup 1, and reuses the same files that stayed the same since backup 1, then you need to keep track of which file needs which key.

Yes, exactly. So your previous comment "back everything up again" does not make sense.

Yes, you need to manage which key is used with each file. And it will be fatal if you lose this mapping. So that's why I offered adding encrypted key to every file. And unfortunately it will raises the file size by several kilobytes :-(. But I do not see better solution.

But when decrypting, you can use some hash of keys and do not do the key decryption for each file, but store already decrypted keys in memory.

[grke]

Yes, it does make sense if you reuse the symmetric key until such time you need to generate a new one.

Example: Backup 1 has 10 files, and uses symmetric key X. Backup 2 has 10 files, 2 of them changed. Burp is able to use symmetric key X to encrypt the two files. Burp is able to decrypt everything from backups 1 and 2 using symmetric key X. Backup 3 has 10 files, 4 of them changed. Burp is not able (for some reason) to use symmetric key X, so it has to generate symmetric key Y and back up all 10 files. Burp is able to decrypt everything from backup 3, but not backups 1 and 2 (until such a time it can use symmetric key X again, for some reason).

Is there some reason the symmetric key has to change between backups? If it is saved with backup 1, can the server not just give it to the client to use again?

[bittner]

Is there some reason the symmetric key has to change between backups?

Remember, myhint in the beginning was to leave everything the same and just change the retrieval function for the symmetric key.

If it is not a complete violation of security best practices why not just leave it the same for an archive?

[bittner]

Maybe I should explain:

My main reason up asking for asymmetric encryption is to make it easier for me as an end-user: I don't want to have to keep an encryption key secretly somewhere, I just want to give my public key to burp and burp should allow me to decrypt the archive with my private key.

[mclei-asw]

Is there some reason the symmetric key has to change between backups? If it is saved with backup 1, can the server not just give it to the client to use again?

Ok I will explain it better.

The combination of symmetric and asymmetric ciphers are used because asymmetric encryption is VERY SLOW. So when encrypting something using asymmetric keys you are doing it this way:

1. Generate TEMPORARY symmetric key!
2. Encrypt the data using this TEMPORARY symmetric key with fast symmetric cipher
3. Encrypt the TEMPORARY symmetric key with all public keys with very slow asymmetric cipher and store it with the encrypted data
4. Throw away the TEMPORARY symmetric key

When when you want to decrypt the data:

1. Take the encrypted symmetric key and decrypt it using one of private keys using asymmetric cipher
2. Decrypt the data using this symmetric key using fast symmetric cipher

The POINT in this schema is that symmetric cipher is used only to speedup the encryption process and that's why the symmetric key is only temporary for the action and is never stored anywhere.

The second POINT is, that you can store only public asymmetric key on the backup machine and nobody is able to decrypt the data even when he has access to the original machine! For decrypting you need private asymmetric key.

The third POINT and also the reason why I am requesting this feature is, that you can use multiple asymmetric keys in common. One server key, that is unique for each server and only the server is able to decrypt its data. And second MASTER key, which is stored in secret and only its public part is placed on every server. So when something wrong happens to the server and I lost its unique key, it is always possible to get the MASTER key out of the safe-deposit box and decrypt any backup.