Re: RFE: Transparent encryption on all fields

-----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@tuxteam.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-----