On Sat, Jul 13, 2019 at 11:58:02PM +0200, Tomas Vondra wrote:
> One extra thing we should consider is authenticated encryption. We can't
> just encrypt the pages (no matter which AES mode is used - XTS/CBC/...),
> as that does not provide integrity protection (i.e. can't detect when
> the ciphertext was corrupted due to disk failure or intentionally). And
> we can't quite rely on checksums, because that checksums the plaintext
> and is stored encrypted.
Uh, if someone modifies a few bytes of the page, we will decrypt it, but
the checksum (per-page or WAL) will not match our decrypted output. How
would they make it match the checksum without already knowing the key.
I read [1] but could not see that explained.
This post discussed it:
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
I realize in a new system we might prefer encrypt-then-mac, TLS and SSL
do it differently, and I don't think the security problems of
MAC-then-Encrypt apply to our use-case, e.g. API programming errors.
If we want to go crazy, we could encrypt, assume zeros for the CRC,
compute the MAC and put it in the place of the CRC is, but then tools
that read CRC would see that as an error, so we don't want to go there.
Yes, crazy.
> Which seems pretty annoying, because then the checksums won't verify
> data as sent to the storage system, and verify checksums would require
> access to all keys (how do you do that in offline mode?).
Uh, the keys are stored in a PGDATA file --- seems simple enough, but we
would either have to do whole-cluster encryption or have some per-page
encryption flag.
> But the main issue with checksum-then-encrypt is it's essentially
> "MAC-then-Encrypt" and that does not provide Authenticated Encryption
> security - see [1]. We should be looking at "Encrypt-then-MAC" instead,
> in which case we'll need to store the MAC somewhere (probably in the
> same place as the nonce/IV/key/... for each page).
I don't think we are planning to store the nonce/IV on each page but
rather use the LSN (already on the page), and perhaps in addition, the
page number.
--
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 +
