Re: New types for transparent encryption

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