Russ Allbery wrote:
Howard Chu firstname.lastname@example.org writes:
I doubt it, of course. It exacts a performance penalty on every DB operation, so I don't think anyone will be able to use this long-term. For the off-site backup scenario, it makes more sense to just encrypt the backup images (tar format or whatever backup utility is used). That way you only spend cycles on encryption once, at backup time. Any site that's savvy enough to do automated backups can certainly figure out how to protect those backups with encryption.
The one place where I could see using this is if one is using OpenLDAP as the backend to a Kerberos KDC. It's considered best practice right now to always encrypt the KDC database at rest on disk, and some sites even require an administrator be present with a USB key to unlock the database whenever a KDC has to be rebooted. Given the increasing interest in using LDAP as a backend store for the KDC, this may be a simpler method for providing equivalent KDC security without encrypting various bits of data individually.
Yes, I guess that's a reasonable scenario. I thought about writing an overlay that can be configured with a list of attributes to encrypt, that just does that before giving an entry to the database. But in that case, you couldn't use indexing to search on any of the encrypted attributes. So encrypting the entire DB makes sense there.