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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Stephen Frost <sfrost(at)snowman(dot)net>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Date: 2019-08-06 00:40:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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(at)momjian(dot)us>

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-08-06 00:42:47 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Previous Message Tatsuo Ishii 2019-08-06 00:25:02 Re: Implementing Incremental View Maintenance