Secure unattended decryption

[eggled at gmail.com]

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
> availability".
> 
> 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.
> 
> 
> Regards,
> 
> 
> 
> 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
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20100319/ae075771/attachment.pgp>