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, ...)
Yes, by definition if it's client side then it can do whatever is most appropriate for that specific client. If the libraries are in some specific language this may or may not make this easier. For example, adding transparent encryption appears to be somewhat trivial to something like haskelldb[1] because it has enough information exposed to it already to do "the right thing". Doing the right thing in languages that don't have this level of detail already exposed, i.e. libpq and most other libraries, is going to be different/harder. Note that I wasn't thinking of haskelldb when I proposed the idea, I just remembered it when trying to think of a good example. > 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.) Yes, that's the point. Client side encryption is about protecting the plaintext from an attacker who has full control of the server. This may or may not be the problem you're trying to solve, but if the attacker doesn't have control over the server then encryption doesn't seem necessary--just use normal permissions and/or views ensure your security properties. > 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). As tomas said, there's a massive difference here. In one, the server is part of your trusted computing base, in another it doesn't have to be. > > 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. OK, but I still don't understand what threat model you're trying to protect against. Which bits of the system are trusted and which bits are assumed malicious? "Trusted" being a technical term from the security world meaning if it goes wrong the security of the system will fail (for example you trust your doctor to respect your privacy and to not kill you), beware that PG uses the term differently with its embedded languages. It appears the main reason you're proposed this is to make it easier for new users to use crypto with their PG database---this seems to be the wrong way around. In my experience, security is hard because determining what's trusted and what's not is difficult. Once you've determined this it's reasonably easy to work the details out and get it implemented. -- Sam http://samason.me.uk/ [1] http://haskelldb.sourceforge.net/haskelldb.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
