-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Apr 25, 2009 at 11:43:14AM +0100, Sam Halliday wrote:
> Please continue to CC me on this thread as I have disabled receiving
> messages from this list, although remain subscribed.
OK
[...]
> 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)
An encrypted partition does most of this (except the "selected columns"
part). Note that encrypting the column most probably will make it
impossible to put an index on that).
so it's +1 for encrypted column.
> - 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. Look
at [1] for an example of how this might be done for the _root partition_
in GNU/Linux (it'll be easier for a dedicated partition, when all else
is up and running).
> - client PSQL queries must remain unchanged (connection request may have
> additional parameters)
Same with encrypted partition.
> - minimal performance penalty, no more than running on top of an encrypted
> drive
Same with encrypted partition.
> 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.
Same with encrypted partition.
There is another advantage of encrypted column mentioned upthread (and I
think it's the main one): each user can unlock her specific data set.
This is cute, but I still think it can be better addressed doing the
decryption client-side (and I maintain that this is _at least as
secure_, possibly even more secure). A drawback would be that each
client would need its own implementation. For the libpq based clients
there is e.g. libpqtypes [2], but non-libpq based (notably Java) would
have to implement that themselves.
I'm still firmly on the camp of "client side", it seems.
[1] <http://gpl.coulmann.de/ssh_luks_unlock.html>
[2] <http://www.postgresql.org/about/news.1021>
Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJ8/mnBcgs9XrR2kYRAqjlAJ9uS1z5xjqhS9AcrbnZc9bobpfO4wCfY4E3
flhU9Rjf9k47iRlnSxs21Oc=
=Abyx
-----END PGP SIGNATURE-----
