-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote: > > Sam Mason <s...@samason.me.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, ...)
Just define a protocol. Of course there is more work in that, so yes, this is one point going against client-side. > 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.) Definitely another point against client-side. *If* there is some random element in encryption (salt, IV, whatever), you can't index on an encrypted field. If there isn't, the encryption will be possibly weak (being amenable at least to a rainbow-table attack). > 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). There definitely is a difference. If someone hi-jacks the running server (trojan, privilege escalation), s/he still doesn'nt get at the data if they only can be decrypted client-side. OTOH, with server-side decryption, all bets are off in this case, since the keys are lying around there (maybe somewhat obfuscated, but still accessible). But this has already been hashed out in another thread AFAIR. Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKWr5FBcgs9XrR2kYRAkbdAJ9JN4mXGE1uD5EGCzWgZh4dsfCPpwCfaTew 2uD3F59+Gm1wR/jnYChvF+M= =WWhL -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
