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