On Wed, Jul 8, 2009 at 1:49 AM, Itagaki Takahiro<itagaki.takah...@oss.ntt.co.jp> wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > >> Greg Stark wrote: >> > It would still protect against offline attacks such as against backup >> > files. >> >> True, but filesystem-level encryption handles that scenario with less pain. > > Yes, I intended offline attacks, and also agree that ilesystem-level > encryption will be a solution. However, as I wrote in the first mail, > standard users want to avoid encrypted filesystems that are not maintained > or supported officially.
I don't see how filesystem encryption helps actually. Your backups are probably filesystem level backups so they will have the decrypted files. Also your archived logs will have the decrypted data, etc. Encrypting the data before it's ever written to disk means you don't have to worry about all the different places your data ends up. Actually pg_dump seems like it would be solvable if you had an escape syntax to indicate that a literal contains the encrypted value in hex. Perhaps something like the bytea syntax we're looking at adopting now. So '\xdeadbeaf'::encrypted_type would be a perfectly valid literal which the user could load even while not knowing what it represents, and that would be what you would get if you access the field, for example with pg_dump, with the guc unset -- just beware you don't run pg_dump set with the guc set to the *wrong* key :) However I have a different concern which hasn't been raised yet. Encrypting lots of small chunks of data with the same key is a very dangerous thing to do and it's very tricky to get right. Merely applying one of the standard stream or block ciphers directly to those short strings will *not* be secure. I think there are techniques for dealing with this but I'm not sure what tradeoffs they have. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers