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

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Sehrope Sarkuni <sehrope@jackdb.com>
Cc: Joe Conway <mail@joeconway.com>, 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-26T00:50:07Z
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 Thu, Jul 25, 2019 at 08:44:40PM -0400, Sehrope Sarkuni wrote:
> On Thu, Jul 25, 2019 at 7:51 PM Bruce Momjian <bruce@momjian.us> wrote:
> 
>     Looking at the bits we have, the IV for AES is 16 bytes.  Since we know
>     we have to use LSN (to change the IV for each page write), and the page
>     number (so WAL updates that change multiple pages with the same LSN use
>     different IVs), that uses 12 bytes:
> 
>             LSN         8 bytes
>             page-number 4 bytes
> 
>     That leaves 4 bytes unused.  If we use CTR, we need 11 bits for the
>     counter to support 32k pages sizes (per Sehrope Sarkuni), and we can use
>     the remaining 5 bits as constants to indicate heap, index, or WAL.
>     (Technically, since we are not encrypting the first 16 bytes, we could
>     use one less bit for the counter.)  If we also use relfilenode, that is
>     4 bytes, so we have no bits for the heap/index/WAL constant, and no
>     space for the CTR counter, meaning we would have to use CBC mode.
> 
> 
> You can still use CTR mode and include those to make the key + IV unique by
> adding them to the derived key rather than the IV.
>
> The IV per-page would still be LSN + page-number (with the block number added
> as it's evaluated across the page) and the relfilenode, heap/index, database,
> and anything else to make it unique can be included in the HKDF to create the
> per-file derived key.

I thought if we didn't have to hash the stuff together we would be less
likely to get collisions with the IV.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +