Re: New types for transparent encryption

On Wed, Jul 8, 2009 at 1:49 AM, Itagaki
Takahiro<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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