Re: RFE: Transparent encryption on all fields

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: tomas(at)tuxteam(dot)de
Cc: Sam Halliday <sam(dot)halliday(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFE: Transparent encryption on all fields
Date: 2009-04-23 14:38:55
Message-ID: 20090423103855.b2ccd033.wmoran@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

In response to tomas(at)tuxteam(dot)de:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Apr 23, 2009 at 12:43:30PM +0100, Sam Halliday wrote:
> > Dear pgsql hackers,
> >
> > The encryption options
> >
> > http://www.postgresql.org/docs/8.3/static/encryption-options.html
>
> [...]
>
> > If it were feasible, a transparent crypto on all fields for a given
> > database would be just the trick! Connections to such databases could
> > require a key as well as the user login [...]
>
> If I understand you correctly you are proposing to do the decryption
> server-side. This doesn't seem to make much sense (at least not beyond
> encrypting the partition where the data is). Either the machine is
> stolen when shut down, or the machine is "stolen" when running. In the
> first case you are fine, in the second you are lost. It's the same as
> with an encrypted partition.
>
> Providing the key/passphrase to unlock the partition is possible over
> the net.
>
> Keeping the (at least the decryption) key client-side makes much more
> sense (and you can provide different clients with different keys). The
> only drawback is when you need an index over an encrypted field :-(

It's possible that this could be accomplished by something like Veil,
or the built-in implementation that's coming in some future version of
PG (is it scheduled for 8.5 at this point?)

Anyway, if a Veil rule required the user to enter a password that would
decrypt their key then store it in the session, this could be used for
subsequent queries to encrypted fields. Since each user has their own
key, the data is protected from all sorts of priv escalations, theft,
etc (really, just about every attack vector aside from password brute
forcing and social engineering ... and those will require other
methods of protection anyway.)

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2009-04-23 14:50:47 PL compilations ignores LDFLAGS
Previous Message Kevin Grittner 2009-04-23 14:36:25 Re: Prepared transactions vs novice DBAs, again