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

Ryan Lambert <ryan@rustprooflabs.com>

From: Ryan Lambert <ryan@rustprooflabs.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Stephen Frost <sfrost@snowman.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, 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:55:44Z
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.

> I didn't either, except it was referenced above as "forward hash".  I
> don't know why that was suggested, which is why I listed it as an
> option/suggestion.

My bad, sorry for the confusion!  I meant to say "cipher" not "hash".  I
was (trying to) refer to the method of generating unpredictable IV from
nonces using the forward cipher function and the encryption key.
Too many closely related words with very specific meanings.

Ryan



>