Re: RFE: Transparent encryption on all fields

From: tomas(at)tuxteam(dot)de
To: Sam Halliday <sam(dot)halliday(at)gmail(dot)com>
Cc: tomas(at)tuxteam(dot)de, Bill Moran <wmoran(at)potentialtech(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFE: Transparent encryption on all fields
Date: 2009-04-27 06:58:33
Message-ID: 20090427065833.GB10909@tomas
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 26, 2009 at 11:54:55AM +0100, Sam Halliday wrote:
> On 26 Apr 2009, at 07:05, tomas(at)tuxteam(dot)de wrote:
>>> - a single psql server can autonomously start up and serve connection
>>> requests (this cannot be done with encrypted disc)
>>
>> Sure it can -- it will be strongly architecture dependent though
>> [...]

> I read the reference and I disagree that this is currently possible.

I didn't try, but knowing how LUKS works I would be very surprised if
that wasn't possible.

> Even
> this example is not an autonomous startup of the psql server. It requires
> an inward network connection, for a start.

I didn't understand that.

> Consider the case where the PSQL
> server is on a laptop and its primary function is to serve local requests,
> therefore "dialling in" over ssh is not an option.

If the sensitive data is in a laptop, the sysadmin should be hit three
times over the head with the newest SQL standard if (s)he doesn't
encrypt the drive in the first place.

> If there were a way to prompt the user for the password to an encrypted
> drive on startup for all OS, with an equivalent for headless machines...

There definitely is. We even need more flexibility: prompt for
credentials at the time of *mounting* a secured partition (this might be
the time you put in a thumb drive, or the time where you take this
particular secured database on-line).

> then perhaps encrypted drives would be practical enough to be used by psql.
> At the moment, the bootup sequence and requirements of psql mean its only
> really an option for user-started servers. An alternative is necessary.

There would be two steps: unlock database (starting the server), connect
to it. If that's unpractical, remember: client-side decryption. The
server _never_ sees the decrypted data (and more important: the
decryption key). The only point of failure is the client (and the client
is a point of failure in any case).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ9VeZBcgs9XrR2kYRAhSVAJ4jm6PxMZ7ZVDsWHt1UjBceNXjscACdHeOJ
Q/DTDRTTCfc858dboD8Dmno=
=ei8t
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Halliday 2009-04-27 08:24:55 Re: RFE: Transparent encryption on all fields
Previous Message Martijn van Oosterhout 2009-04-27 06:21:23 Re: To know what a macro does