Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Joe Conway <mail@joeconway.com>, Antonin Houska <ah@cybertec.at>, Stephen Frost <sfrost@snowman.net>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-26T03:30:55Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revamp the WAL record format.
- 2c03216d8311 9.5.0 cited
On 2019-Jul-25, Alvaro Herrera wrote: > > Uh, there are no known attacks on AES with known plain-text, e.g., SSL > > uses AES, so I think we are good with encrypting everything after the > > first 16 bytes. > > Well, maybe there aren't any attacks *now*, but I don't know what will > happen in the future. I'm not clear what's the intended win by > encrypting the all-zeroes page hole anyway. If you leave it > unencrypted, the attacker knows the size of the hole, as well as the > size of the tuple data area and the size of the LP array. Is that a > side-channer that leaks much? This answer https://crypto.stackexchange.com/a/31090 is interesting for three reasons: 1. it says we don't really have to worry about cleartext attacks, at least not in the immediate future, so encrypting the hole should be OK; 2. it seems to reinforces a point I tried to make earlier, which is that reusing the IV a small number of times is *not that bad*: > On the other hand if the Key and IV are reused between messages then > the same plaintext will lead to the same ciphertext, so you can > potentially decrypt a message using a sufficiently large corpus of known > matching plaintext/ciphertext pairs, even without ever recovering the > key. Actually the attack being described presumes that you know *both the* *unencrypted data and the encrypted data* for a certain key/IV pair, and only then you can decrypt some other data. It doesn't follow that you can decrypt data just because somebody reused the IV for a second page ... I haven't seen any literature referenced that explains what this attack is. 3. It seems clear that AES is sufficiently complicated that explaining it to non-cryptographers is a lost cause. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services