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
> "has" all the necessary key material to decrypt the data you are't
> 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
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
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2009-04-25 15:53:57|
|Subject: Re: Copyright waiver from Helios (fix for non-BSD
|Previous:||From: Grzegorz Jaskiewicz||Date: 2009-04-25 10:42:37|
|Subject: Re: HashJoin w/option to unique-ify inner rel|