On Mon, Jun 18, 2018 at 09:49:20AM -0400, Robert Haas wrote:
> 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
Most encryption methods use a random initialization vector (IV) for each
encryption, e.g. pgp_sym_encrypt(), but length might allow this, as you
stated.
> know the ordering of the values under whatever ordering semantics
> apply to that index. It's unclear to me how useful such information
I don't think an ordered index is possible, only indexing of encrypted
hashes, i.e. see this and the next slide:
https://momjian.us/main/writings/crypto_hw_use.pdf#page=86
> 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.
Yes, that is a benefit that is not possible with page-level encryption.
It also encrypts the WAL and backups automatically; see:
http://momjian.us/main/writings/crypto_hw_use.pdf#page=97
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
