On Mon, Jul 29, 2019 at 4:15 PM Alvaro Herrera <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 Regards, -- Sehrope Sarkuni Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
