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-----
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 |