Dan Langille wrote:
On 5 Feb 2006 at 18:33, Landon Fuller wrote:In the spirit of status reports -- Bacula's File Daemon now has complete support for signing and encryption data prior to sending it to the Storage Daemon, and decrypting said data upon receipt from the Storage Daemon.Now that's pretty cool!
Thanks!
How does it work? Just simple public key encryption type thing?
Right - a session key is randomly generated for each backup job, and that session key is then encrypted using "recipients'" public keys. By specifying multiple public keys, one can specify multiple recipients that may decrypt the backup.
The downside to the current implementation is that a copy of the encrypted session keys is saved with *every file*. The size of this data structure isn't huge, but it does add up. If I recall correctly, with a single 2048 bit key the on disk structure was ~280 bytes. For 100,000 files, that adds up to 26 megabytes.
I'm not sure how much of an issue this is for potential users of FD-side data encryption. The upside is that the backups are much more resilient to tape/disk corruption.
As far as generating the keys, I'm just using self-signed PEM encoded x509 certificates and private keys. They be generated with a couple openssl(1) one-liners.
One other issue worth raising -- The director can currently overwrite any file on the FD, including the encryption keys or the FD configuration file, thus exposing private data to the director.
I thought that we could solve this by either:1) Provide a "Allow Restore" flag that allows one to disable restoration until it's actually needed, or 2) Provide a "Restore Root" directive that allows the specification of a restoration root under which all restored files must live. I prefer this option, but 1) is certainly easier.
Thoughts?
There is a small memory leak I need to track down, and some remaining bits and pieces to implement, but I wanted to fill everyone in on the current status before another weekend slipped by.That's always the case... pretty hard to track down too I bet.
I really do love valgrind ... =)
I've been using the TLS feature for a few weeks now. I'm pretty happy with it. It's been working every time withojut fail. No more stunnel for me.
Glad to hear it. We've been using the TLS implementation ever since the tail-end of the 1.37 release cycle, zero problems. One feature I'd really like to see is the implementation of SSH-style public key validation -- caching the public key on first connect and then validating against the cache. It'd be a nice alternative to maintaining x509 infrastructure. I don't know when I'll have time to tackle the problem, but if anyone is interested in the project I'd be happy to provide some pointers. It's not too hard to do ...
-landonf
signature.asc
Description: OpenPGP digital signature
