Re: New types for transparent encryption

Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:

> As others have said, handling encryption client side would seem to offer
> many more benefits (transparently within libpq offering easy adoption).

Libpq is not the only driver. Do we need to develop transparent decryption
for each drivers? (libpq, JDBC, npgsql, py-postgresql, ...)

Also, if you disallow server-side decode, you cannot create indexes on
encrypted values because the same values are not always encrypted to the
same codes. (Indexes will sort keys based on order of decoded values.)

I think there is no difference between client-side decryption and
clinet-supplied password as far as clinet-server communication is
encrypted (i.e, SSL login).

> Should the password be this widely shared? it would seem to make more
> sense if it was a write-only variable and never exposed outside the
> crypto module.

We can use an user-defined GUC variables as a write-only variable.
When we supply some show_hook function to GUC variable,
SET still works but SHOW only shows '****' and hides real passwords.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center