On 2019-Jul-15, Bruce Momjian wrote: > 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 find all the discussion downthread from this post pretty confusing. Why are we encrypting the page header in the first place? It seems to me that the encrypted area should cover only the line pointers and the tuple data area; the page header needs to be unencrypted so that it can be used at all: firstly because you need to obtain the LSN from it in order to compute the IV, and secondly because the checksum must be validated *before* decrypting (per Moxie Marlinspike's "cryptographic doom" principle mentioned in a comment in the SE question). I am not totally clear on whether the special space and the "page hole" need to be encrypted. I tend to think that they should *not* be encrypted; in particular, encrypting a large area containing zeroes seem a plentiful source of known cleartext, which seems a bad thing. Special space also seems to contain known cleartext; maybe not as much as the page hole, but still seems better avoided. Given this, it seems to me that we should first encrypt those two data areas, and *then* compute the CRC on the complete page just like we do today ... and the result is stored in an unencrypted area (the page header) and so it doesn't affect the encryption. The checksum we currently have is not cryptographically secure -- it's not a crypto-strong signature. If we want that, we need some further protection. Maybe for encrypted tables we replace our current checksum with an cryptographically secure signature ...? Pretty sure 16 bits are insufficient for that, but I suppose we would just use a different page header with room for a proper sig. Am I misunderstanding something? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
