Secure unattended decryption
eggled at gmail.com
eggled at gmail.com
Fri Mar 19 21:26:09 CET 2010
On Fri, Mar 19, 2010 at 02:17:12PM -0300, M.B.Jr. wrote:
> Hi Daniel,
> On Thu, Mar 18, 2010 at 8:50 AM, Daniel Eggleston <eggled at gmail.com> wrote:
> > I know it's sort of a contradiction in terms, but hear me out:
> > The case I'm looking at is a High Availability environment hosting a
> > database. The database is comprised of many Unix files, encrypted via AES,
> > on shared storage. If the node accessing the database loses enough of its
> > redundant hardware that it can no longer function as the database server,
> > control must failover to the secondary node. Since the client systems are
> > the priority, the goal is the shortest downtime possible.
> > The encryption key for the databases is stored on-disk, encrypted with PGP
> > (Gnupg specifically).
> Sort of a conceptual remark at this point.
> See, this database password you refer to is a symmetrical one. And you
> stated you keep it on-disk, encrypted with GnuPG.
> So, is this last GnuPG encryption also symmetrical?
> If so, and if your DBA is GnuPG's password keeper, GnuPG's encryption
> would make little sense, considering you're concerned with "high
> It would be more sensible to cease that encryption cascading
> (databases's AES + GnuPG's some supposedly symmetrical algo) and let
> your DBA carry somehow the AES clear text password, directly.
> Check your database's documentation. Perhaps it could maintain
> authentication after a failover. And chances increase in redundant
> environments, if the referred system depends only on its own
> encryption resources.
> Marcio Barbado, Jr.
Yes, well, changing the AES key on a database (Which may be several
hundred gigabytes) is time consuming. Changing a GPG passphrase is not.
Using assymetric encryption of the AES key using GPG makes it very easy
to change the gpg encryption key passphrase regularly.
Thanks for the input; I agree that in general the cascading encryption
would be cumbersome and not worthwhile, but it's been carefully
considered, and the method chosen was not by mistake.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the Gnupg-users