Horton

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

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Joe Conway <mail@joeconway.com>, Antonin Houska <ah@cybertec.at>, Stephen Frost <sfrost@snowman.net>, 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-08-06T00:40:14Z
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 Wed, Jul 31, 2019 at 03:29:59PM +0900, Masahiko Sawada wrote:
> Just to confirm, we have 21 bits left for nonce in CTR? We have LSN (8
> bytes), page-number (4 bytes) and counter (11 bits) in 16 bytes nonce
> space. Even though we have 21 bits left we cannot store relfilenode to
> the IV.

No.  The nonce is the LSN and page number, the CTR counter (11 bits),
and 21 extra bits.  CTR needs a nonce for every 16-byte block, if you
want to think of it that way.

Even though there isn't space for the relfilenode in the nonce, We could
use the relfilenode/tablespace/database id by mixing into a derived key,
based on the master key, but as I stated in another email, we don't want
do that unles we have to.

> BTW I've received a review about the current design by some
> cryptologists in our company. They recommended to use CTR rather than
> CBC. The main reason is that in block cipher it's important to ensure
> the uniqueness even for every input block to the block cipher. CBC is
> hard to ensure that because the previous output is the next block's
> input. Whereas in CTR, it encrypts each blocks separately with
> key+nonce. Therefore if we can ensure the uniqueness of IV we can meet
> that. Also it's not necessary to encrypt IV as it's okey to be
> predictable. So I vote for CTR for at least for tables/indexes
> encryption, there already might be consensus though.

Yes, you are more likely to get duplicate nonce in CBC mode rather than
the CTR mode we are proposing.

-- 
  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 +