In response to tomas@tuxteam.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/
