On Mon, Jul 15, 2019 at 03:47:59AM +0200, Tomas Vondra wrote:
> On Sun, Jul 14, 2019 at 12:13:45PM -0400, Joe Conway wrote:
> > We could check the CRC prior to encryption and throw an ERROR if it is
> > not correct. After decryption we can check it again -- if it no longer
> > matches we would know there way a corruption or change of the
> > ciphertext, no?
> >
> > Hmm, I guess the entire page of ciphertext could be faked including CRC,
> > so this would only really cover corruption, not an intentional change if
> > it were done properly.
> >
>
> I don't think any of the schemes discussed here provides protection
> against this sort of replay attacks (i.e. replacing a page with an older
> copy of the page). That would probably require having some global
> checksum or something like that.
Uh, I think the only thing we could do is to add the page number into
the nonce so the page would have to be replaced in the same place in the
table, but it hardly seems worth it.
> > > 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?).
> >
> > Given the scheme above I don't see why that would be an issue. The keys
> > are all accessible via the MDEK, which is in turn available via the KEK.
> >
>
> I just don't know how the offline tools will access the KMS to get the
> keys. But maybe that's not an issue. But even then I think it's kinda
> against the idea of checksums that they would not checksum what was sent
> to the storage system.
Oh, I see your point now. pgchecksum will look at the page and think it
is corrupt. It would need access to the keys to verify it, and only for
whole-cluster encryption or if there is a per-page flag (it can't easily
do system table lookups).
The crazy seems more sane now --- "encrypt the page with CRC contents as
zero" (which we probably already do to compute the CRC), then compute
the CRC, and modify the page CRC.
I kind of feel we need to decide this now so our tooling can plan for it.
--
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 +