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

Thank you for summarizing the discussion, it's really helpful. I'll
update the wiki page based on the summary.

On Fri, Jul 12, 2019 at 10:05 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > The keys themselves should be in an file which is encrypted by a master
> > key. Obtaining the master key should be pattern it after the GUC
> > ssl_passphrase_command.

+1.
I will update the patch set based on the decision on this thread.

> >
> > > We will use CBC AES128 mode for tables/indexes, and CTR AES128 for WAL.
> > > 8k pages will use the LSN as a nonce, which will be encrypted to
> > > generate the initialization vector (IV). We will not encrypt the first
> > > 16 bytes of each pages so the LSN can be used in this way. The WAL will
> > > use the WAL file segment number as the nonce and the IV will be created
> > > in the same way.
> >
> > I vote for AES 256 rather than 128.
>
> Why? This page seems to think 128 is sufficient:
>
> https://crypto.stackexchange.com/questions/20/what-are-the-practical-differences-between-256-bit-192-bit-and-128-bit-aes-enc
>
> For practical purposes, 128-bit keys are sufficient to ensure security.
> The larger key sizes exist mostly to satisfy some US military
> regulations which call for the existence of several distinct "security
> levels", regardless of whether breaking the lowest level is already far
> beyond existing technology.
>
> We might need to run some benchmarks to determine the overhead of going
> to AES256, because I am unclear of the security value.

'openssl speed' will help to see the performance differences easily.
FWIW I got the following result in my environment (Intel(R) Core(TM)
i7-3770 CPU @ 3.40GHz).

$ openssl speed -evp aes-128-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 642449.60k 656404.63k 700231.23k 706461.71k 706051.44k

$ openssl speed -evp aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 466787.73k 496237.08k 503477.16k 507113.32k 508453.80k

Regarding the security value, I found an interesting post by Bruce Schneier.

https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

"And for new applications I suggest that people don't use AES-256.
AES-128 provides more than enough security margin for the forseeable
future. But if you're already using AES-256, there's no reason to
change."

>
> > Did we determine that we no longer need table oid because LSNs are
> > sufficiently unique?
>
> I think so.
>
> > > wal_log_hints will be enabled automatically in encryption mode, like we
> > > do for checksum mode, so we never encrypt different 8k pages with the
> > > same IV.
> >
> > check
> >
> > > There will need to be a pg_control field to indicate that encryption is
> > > in use.
> >
> > I didn't see that discussed but it makes sense.
>
> Yes, it seems to make sense, but was not discussed.
>
> > > Right now we don't support the online changing of a cluster's checksum
> > > mode, so I suggest we create a utility like pg_checksums --enable to
> > > allow offline key rotation. Once we get online checksum mode changing
> > > ability, we can look into use that for encryption key rotation.
> >
> > Master key rotation should be trivial if we do it the way I discussed
> > above. Rotating the individual heap and WAL keys would certainly be a
> > bigger problem.
>
> Yes, sorry, master key rotation is simple. It is encryption key
> rotation that I think needs a tool.

Agreed.

To rotate the master key we can have a SQL function or dedicated SQL
command passing the new master key or the passphrase to postgres.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center