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 <br...@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 +
