Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) - Mailing list pgsql-hackers

On Sat, Jul 13, 2019 at 02:41:34PM -0400, Joe Conway wrote:
> On 7/13/19 9:38 AM, Joe Conway wrote:
> ---
> [1] and [2] show that at least some file system encryption uses a
> different key per file.

Yes, I see later they did that for per-file keys, but I think with WAL
and crash recovery we decided there was little value in trying that
since all keys would need to be online for recovery.

> ---
> [2] also shows that file system encryption uses a KDF (key derivation
> function) which we may want to use ourselves. The analogy would be
> per-table derived key instead of per file derived key. Note that KDF is
> a safe way to derive a key and it is not the same as a "related key"
> which was mentioned on another email as an attack vector.
> ---
> [2] also says provides additional support for AES 256. It also mentions
> CBC versus XTS -- I came across this elsewhere and it bears discussion:
> 
> "Currently, the following pairs of encryption modes are supported:
> 
>     AES-256-XTS for contents and AES-256-CTS-CBC for filenames
>     AES-128-CBC for contents and AES-128-CTS-CBC for filenames
>     Adiantum for both contents and filenames
> 
> If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair.
> 
> AES-128-CBC was added only for low-powered embedded devices with crypto
> accelerators such as CAAM or CESA that do not support XTS."

It would be nice to understand what XTS adds to CBC.

> [5] has this to say which seems independent of mode:
> 
> "When encrypting data with a symmetric block cipher, which uses blocks
> of n bits, some security concerns begin to appear when the amount of
> data encrypted with a single key comes close to 2n/2 blocks, i.e. n*2n/2
> bits. With AES, n = 128 (AES-128, AES-192 and AES-256 all use 128-bit
> blocks). This means a limit of more than 250 millions of terabytes,
> which is sufficiently large not to be a problem. That's precisely why
> AES was defined with 128-bit blocks, instead of the more common (at that
> time) 64-bit blocks: so that data size is practically unlimited."
> 
> But goes on to say:
> "I wouldn't use n*2^(n/2) bits in any sort of recommendation. Once you
> reach that number of bits the probability of a collision will grow
> quickly and you will be way over 50% probability of a collision by the
> time you reach 2*n*2^(n/2) bits. In order to keep the probability of a
> collision negligible I recommend encrypting no more than n*2^(n/4) bits
> with the same key. In the case of AES that works out to 64GB"
>
> It is hard to say if that recommendation is per key or per key+IV.

When they mention collision, are they assuming a random nonce?  I am
guessing they do, I think the LSN avoids that problem because we
effectively have a counter.

> ---
> [6] shows that Azure SQL Database uses AES 256 for TDE. It also seems to
> imply a single key is used although at one point it says "transparent
> data encryption master key, also known as the transparent data
> encryption protector". The term "master key" indicates that they likely
> use derived keys under the covers.
> ---
> [7] is generally useful read about how many of the things we have been
> discussing are done in SQL Server
> ---
> [8] was referenced by Sehrope. In addition to support for AES 256 for
> long term use, table 5.1 is interesting. It lists CBC mode as "legacy"
> but not "future".

Interesting.  Is the a reason stated?

> ---
> [9] IETF RFC for KDF
> ---
> [10] IETF RFC for Key wrapping -- this is probably how we should wrap
> the master key with the Key Encryption Key (KEK) -- i.e. the outer key
> provided by the user or command on postmaster start

Yes, I think we all agreed to have a passphrase to lock the encryption
keys.

> ---
> 
> Based on all of that I cannot find a requirement that we use more than
> one key per database.

You mean cluster, right?  That is great news!

> But I did find that files in an encrypted file system are encrypted with
> derived keys from a master key, and I view this as analogous to what we
> are doing.

Agreed.

> As an aside to the specific question, I also found more evidence that
> AES 256 is appropriate.

I think we should allow the AES128/AES256 to be optional on version 1 of
the feature, or at least call the initdb option --encrypt-aes128, like
we did with SCRAM, so we have a clear path to adding AES256.

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