Re: RFE: Transparent encryption on all fields - Mailing list pgsql-hackers

From Sam Mason
Subject Re: RFE: Transparent encryption on all fields
Date
Msg-id 20090427125526.GR12225@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: RFE: Transparent encryption on all fields  (Sam Halliday <sam.halliday@gmail.com>)
Responses Re: RFE: Transparent encryption on all fields  (Sam Halliday <sam.halliday@gmail.com>)
Re: RFE: Transparent encryption on all fields  (Sam Halliday <sam.halliday@gmail.com>)
List pgsql-hackers
On Mon, Apr 27, 2009 at 09:24:55AM +0100, Sam Halliday wrote:
> Not looking for a Windows solution. Must be cross platform and work  
> for headless machines, laptops and desktops. Encrypted drive solutions  
> fall short of these requirements. Other considerations which rule out  
> encrypted drives have been discussed earlier in the thread.

Just for reference; TrueCrypt is for Mac OS/X and Linux.  Never tried it
on them, but it's supposed to work!

> For the record, I have a working solution at the moment that involves  
> using an encrypted drive and a manual per-user startup sequence. *I am  
> not looking for user advice*, this is an RFE for an additional server- 
> side encryption approach to security.

OK, I've just re-read your original messages--my mail client had decided
to break the thread into several pieces and I think I've put it all back
together now and have an idea what you're after.

As far as I can tell, it would currently be somewhat hard with PG the
way it's currently implemented.  It assumes shared access to various
catalogue tables and I don't think these couldn't be encrypted (I
believe they're needed during database startup).

One possible arrangement would be if each user/encryption key had its
own database cluster.  If that's OK, then maybe you could hack pg-pool
around so that once it received the secret it would be able to run off,
mount the appropriate partitions, and start the database engine before
connecting to it.  I've not used pg-pool before, but have a feeling
that it can re-write queries on the fly so must have some non-trivial
protocol knowledge--I may be wrong about that though.

Allowing multiple users/encryption keys access the same database seems
problematic; how would you allow catalogue access and enforce unique or
other constraints if the server couldn't look to see what's there.  Not
sure what you're after here though.

--  Sam  http://samason.me.uk/


pgsql-hackers by date:

Previous
From: Werner Echezuria
Date:
Subject: Re: To know what a macro does
Next
From: Heikki Linnakangas
Date:
Subject: Re: Clean shutdown and warm standby