On 7/29/19 6:11 PM, Sehrope Sarkuni wrote: > On Mon, Jul 29, 2019 at 4:15 PM Alvaro Herrera <alvhe...@2ndquadrant.com > <mailto:alvhe...@2ndquadrant.com>> wrote: > > On 2019-Jul-27, Sehrope Sarkuni wrote: > > > 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. > > But what attack are we protecting against? We fear that somebody will > steal a disk or a backup. We don't fear that they will *write* data. > The CRC is there to protect against data corruption. So whether or not > the CRC protects against malicious tampering is beside the point. > > > That was in response to using an encrypted CRC for tamper detection. I > agree that it does not provide meaningful protection so there is no > point in adding complexity to use it for that. > > I agree it's better to leave the CRC as-is for detecting corruption > which also has the advantage of playing nice with existing checksum tooling. > > > If we were trying to protect against an attacker having access to > *writing* data in the production server, this encryption scheme is > useless: they could just as well read unencrypted data from shared > buffers anyway. > > > The attack situation is someone being able to modify pages at the > storage tier. They cannot necessarily read server memory or the > encryption key, but they could make changes to existing data or an > existing backup that would be subsequently read by the server. > > Dealing with that is way out of scope but similar to the replica > promotion I think it should be kept track of and documented. > > > I think trying to protect against malicious data tampering is a second > step *after* this one is done. > > > +1
Well said; +1 Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature
