Re: New types for transparent encryption

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: New types for transparent encryption
Дата
Msg-id 407d949e0907072256r615a043cuada058c7a5210b52@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New types for transparent encryption  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Brendan Jurd
Дата:
Сообщение: Re: [pgsql-www] commitfest.postgresql.org
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Re: Synch Rep: direct transfer of WAL file from the primary to the standby