Re: New types for transparent encryption

On Wed, Jul 8, 2009 at 6:43 AM, Itagaki
Takahiro<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
>
> tomas(at)tuxteam(dot)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