Horton

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

Joe Conway <mail@joeconway.com>

View thread
From: Joe Conway <mail@joeconway.com>
To: Sehrope Sarkuni <sehrope@jackdb.com>, Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Bruce Momjian <bruce@momjian.us>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Antonin Houska <ah@cybertec.at>, Stephen Frost <sfrost@snowman.net>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-29T22:27:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revamp the WAL record format.

On 7/29/19 6:11 PM, Sehrope Sarkuni wrote:
> On Mon, Jul 29, 2019 at 4:15 PM Alvaro Herrera <alvherre@2ndquadrant.com
> <mailto:alvherre@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