Skip site navigation (1) Skip section navigation (2)

Re: RFE: Transparent encryption on all fields

From: tomas(at)tuxteam(dot)de
To: Sam Halliday <sam(dot)halliday(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFE: Transparent encryption on all fields
Date: 2009-04-23 14:35:49
Message-ID: 20090423143549.GA21006@tomas (view raw or flat)
Thread:
Lists: pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 23, 2009 at 12:43:30PM +0100, Sam Halliday wrote:
> Dear pgsql hackers,
>
> The encryption options
>
>   http://www.postgresql.org/docs/8.3/static/encryption-options.html

[...]

> If it were feasible, a transparent crypto on all fields for a given 
> database would be just the trick! Connections to such databases could 
> require a key as well as the user login [...]

If I understand you correctly you are proposing to do the decryption
server-side. This doesn't seem to make much sense (at least not beyond
encrypting the partition where the data is). Either the machine is
stolen when shut down, or the machine is "stolen" when running. In the
first case you are fine, in the second you are lost. It's the same as
with an encrypted partition.

Providing the key/passphrase to unlock the partition is possible over
the net.

Keeping the (at least the decryption) key client-side makes much more
sense (and you can provide different clients with different keys). The
only drawback is when you need an index over an encrypted field :-(

Regards
- -- tomás


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ8HzFBcgs9XrR2kYRAlcMAJ4irB6+J0/8KxSpDFKCidRyVkA6cgCeKSBi
UqMNLQ1QLrYGsb0YZ+d1aNY=
=RSOK
-----END PGP SIGNATURE-----

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-04-23 14:36:25
Subject: Re: Prepared transactions vs novice DBAs, again
Previous:From: Fujii MasaoDate: 2009-04-23 14:29:16
Subject: Re: Synch Replication: Synchronization of files between Primary & Standby

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group