Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Sat, Jul 27, 2019 at 03:02:02PM -0400, Sehrope Sarkuni wrote:
> On Sat, Jul 27, 2019 at 1:32 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Uh, I listed the three options for the CRC and gave the benefits of
> > each:
> >
> > https://www.postgresql.org/message-id/20190725200343.xo4dcjm5azrfn6zr@momjian.us
> >
> > Obviously I was not clear on the benefits. To quote:
> >
> > 1. compute CRC and then encrypt everything
> > 3. encrypt and then CRC, and store the CRC encrypted
> >
> > Numbers 1 & 3 give us tampering detection, though with the CRC being so
> > small, it isn't totally secure.
> >
> > > Are you worried about an attacker forging the page checksum by
> > > installing another encrypted page that gives the same checksum? I'm not
> > > sure how that attack works ... I mean why can the attacker install
> > > arbitrary pages?
> >
> > Well, with #2
> >
> > 2 encrypt and then CRC, and store the CRC unchanged
> >
> > you can modify the page, even small parts, and just replace the CRC to
> > match your changes. In #1 and #3, you would get a CRC error in almost
> > all cases since you have no way of setting the decrypted CRC without
> > knowing the key. You can change the encrypted CRC, but the odds that
> > the decrypted one would match the page is very slim.
>
> Regarding #1 and #3, with CTR mode you do not need to know the key to
> make changes to the CRC. Flipping bits of the encrypted CRC would flip
> the same bits of the decrypted one. This was one of the issues with
> the older WiFi encryption standard WEP[1] which used RC4 + CRC32. It's
> not the exact same usage pattern, but I wouldn't be surprised if there
> is a way to make in place updates and matching CRC32 changes even if
> it's encrypted.

I see.

> Given the non-cryptographic nature of CRC and its 16-bit size, I'd
> round down the malicious tamper detection it provides to zero. At best
> it catches random disk errors so might as well keep it in plain text
> and checkable offline.

OK, zero is pretty low. ;-) Let's just go with #2 then, and use CTR
mode so it is easy to skip the CRC bytes in the page.

> More generally, without a cryptographic MAC I don't think it's
> possible to provide any meaningful malicious tamper detection. And
> even that would have to be off-page to deal with page replay (which I
> think is out of scope).

Yeah.

--
Bruce Momjian <bruce(at)momjian(dot)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 +