Re: RFE: Transparent encryption on all fields

From: Sam Halliday <sam(dot)halliday(at)gmail(dot)com>
To: tomas(at)tuxteam(dot)de
Cc: Bill Moran <wmoran(at)potentialtech(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFE: Transparent encryption on all fields
Date: 2009-04-25 10:43:14
Message-ID: 4FAEDDE1-6DEF-436A-844D-4C64FE8B2137@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Please continue to CC me on this thread as I have disabled receiving
messages from this list, although remain subscribed.

On 25 Apr 2009, at 05:52, tomas(at)tuxteam(dot)de wrote:
>> Sure, there are challenges, but there are methods to work through all
>> of those challenges.
>
> I seem to be less optimistic than you are: I think as soon as the
> server
> "has" all the necessary key material to decrypt the data you are't
> more
> secure than a "traditional" system, with some access control.

Remember, the threat case here is a stolen server/desktop/laptop which
is either completely locked down or has been powered off. The secure
transmission of keys is someone else's problem.

This is essentially a proposal to get around the limitations imposed
by running PostgreSQL on an encrypted partition. The requirements are
the following, regardless of how it is implemented:-

- data for selected databases/columns are stored encrypted on disc,
passwords not persisted (although may remain in RAM)
- a single psql server can autonomously start up and serve connection
requests (this cannot be done with encrypted disc)
- client PSQL queries must remain unchanged (connection request may
have additional parameters)
- minimal performance penalty, no more than running on top of an
encrypted drive

Of course if an intruder has physical access to the device AND the
keys, then all is lost. That is always the case. But that's 2
intrusions they must make.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-04-25 15:53:57 Re: Copyright waiver from Helios (fix for non-BSD copyright)
Previous Message Grzegorz Jaskiewicz 2009-04-25 10:42:37 Re: HashJoin w/option to unique-ify inner rel