On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: > On 6/15/19 9:28 PM, Bruce Momjian wrote: > >> There are reasons other than performance to want more granular than > >> entire cluster encryption. Limiting the volume of encrypted data with > >> any one key for example. And not encrypting #1 & 2 above would help > >> avoid known-plaintext attacks I would think. > > > > There are no known non-exhaustive plaintext attacks on AES: > > > > > > https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks > > Even that non-authoritative stackexchange thread has varying opinions. > Surely you don't claim that limiting know plaintext as much as is > practical is a bad idea in general.
I think we have to look at complexity vs. benefit. > > Even if we don't encrypt the first part of the WAL record (1 & 2), the > > block data (3) probably has enough format for a plaintext attack. > > Perhaps. > > In any case it doesn't address my first point, which is limiting the > volume encrypted with the same key. Another valid reason is you might > have data at varying sensitivity levels and prefer different keys be > used for each level. That seems quite complex. > And although I'm not proposing this for the first implementation, yet > another reason is I might want to additionally control "transparent > access" to data based on who is logged in. That could be done by > layering an additional key on top of the per-tablespace key for example. > > The bottom line in my mind is encrypting the entire database with a > single key is not much different/better than using filesystem > encryption, so I'm not sure it is worth the effort and complexity to get > that capability. I think having the ability to encrypt at the tablespace > level adds a lot of capability for minimal extra complexity. I disagree. -- Bruce Momjian <br...@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 +