Re: New types for transparent encryption - Mailing list pgsql-hackers

From Greg Stark
Subject Re: New types for transparent encryption
Date
Msg-id 407d949e0907072256r615a043cuada058c7a5210b52@mail.gmail.com
Whole thread Raw
In response to Re: New types for transparent encryption  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
On Wed, Jul 8, 2009 at 6:43 AM, Itagaki
Takahiro<itagaki.takahiro@oss.ntt.co.jp> wrote:
>
> tomas@tuxteam.de wrote:
>
>> As other posters have put it, I'd be very sceptical of server-side
>> decryption. If the server "has" all the necessary bits to decrypt the
>> data, all bets are off.
>
> Server can access both encrypted data and its password, but we can put
> them in different disk drives. We cannot decrypt the data unless we have
> all copies of the drives.

I thought the proposal was to have a GUC variable with the password,
so it would be purely in memory. I had assumed the application would
have the password and call SET early in the connection. Perhaps only
certain components of the database would actually have access to the
password. That makes a lot more sense in these ajaxy soapy days of web
2.0 where perhaps only the payment processing soap service would
actually have the password to encrypt credit card details. (Though in
that case I would expect the soap service to do the encryption
itself....)

-- 
greg
http://mit.edu/~gsstark/resume.pdf


pgsql-hackers by date:

Previous
From: Brendan Jurd
Date:
Subject: Re: [pgsql-www] commitfest.postgresql.org
Next
From: Fujii Masao
Date:
Subject: Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby