Re: New types for transparent encryption

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
>
> 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, ...)

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-----