On Wed, Jun 13, 2018 at 9:20 AM, Joe Conway <m...@joeconway.com> wrote: >> Also, if I understand correctly, at unconference session there also >> were two suggestions about the design other than the suggestion by >> Alexander: implementing TDE at column level using POLICY, and >> implementing TDE at table-space level. The former was suggested by Joe >> but I'm not sure the detail of that suggestion. I'd love to hear the >> deal of that suggestion. > > The idea has not been extensively fleshed out yet, but the thought was > that we create column level POLICY, which would transparently apply some > kind of transform on input and/or output. The transforms would > presumably be expressions, which in turn could use functions (extension > or builtin) to do their work. That would allow encryption/decryption, > DLP (data loss prevention) schemes (masking, redacting), etc. to be > applied based on the policies.
It seems to me that column-level encryption is a lot less secure than block-level encryption. I am supposing here that the attack vector is stealing the disk. If all you've got is a bunch of 8192-byte blocks, it's unlikely you can infer much about the contents. You know the size of the relations and that's probably about it. If you've got individual values being encrypted, then there's more latitude to figure stuff out. You can infer something about the length of particular values. Perhaps you can find cases where the same encrypted value appears multiple times. If there's a btree index, you know the ordering of the values under whatever ordering semantics apply to that index. It's unclear to me how useful such information would be in practice or to what extent it might allow you to attack the underlying cryptography, but it seems like there might be cases where the information leakage is significant. For example, suppose you're trying to determine which partially-encrypted record is that of Aaron Aardvark... or this guy: https://en.wikipedia.org/wiki/Hubert_Blaine_Wolfeschlegelsteinhausenbergerdorff,_Sr. Recently, it was suggested to me that a use case for column-level encryption might be to prevent casual DBA snooping. So, you'd want the data to appear in pg_dump output encrypted, because the DBA might otherwise look at it, but you wouldn't really be concerned about the threat of the DBA loading a hostile C module that would steal user keys and use them to decrypt all the data, because they don't care that much and would be fired if they were caught doing it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
