Horton

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

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Ryan Lambert <ryan@rustprooflabs.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Joe Conway <mail@joeconway.com>, Antonin Houska <ah@cybertec.at>, Masahiko Sawada <sawada.mshk@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.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-10T18:41:42Z
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.

Greetings,

* Ryan Lambert (ryan@rustprooflabs.com) wrote:
> > what is it that gets stored in the page for
> > decryption use, the nonce or the IV derived from it?
> 
> I believe storing the IV is preferable and still secure per [1]: "The IV
> need not be secret"
> 
> Beyond needing the database oid, if every decrypt function has to
> regenerate the IV from the nonce that will affect performance.  I don't
> know how expensive the forward hash is but it won't be free.

Compared to the syscall and possible disk i/o required, I'm not sure
that's something we really need to try to optimize for, particularly if
we could store something more generally useful (like the LSN) in that
little bit of space that's available in each page.

Thanks,

Stephen