On Sat, Jul 27, 2019 at 03:02:02PM -0400, Sehrope Sarkuni wrote: > On Sat, Jul 27, 2019 at 1:32 PM Bruce Momjian <br...@momjian.us> wrote: > > Uh, I listed the three options for the CRC and gave the benefits of > > each: > > > > > > https://www.postgresql.org/message-id/20190725200343.xo4dcjm5azrfn...@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 <br...@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 +
