On Fri, Jul 26, 2019 at 02:54:04AM +0900, Masahiko Sawada wrote: > On Fri, Jul 26, 2019 at 2:18 AM Bruce Momjian <br...@momjian.us> wrote: > > > > On Thu, Jul 18, 2019 at 12:04:25PM +0900, Masahiko Sawada wrote: > > > I've re-considered the design of TDE feature based on the discussion > > > so far. The one of the main open question is the granular of > > > encryption objects: cluster encryption or more-granular-than-cluster > > > encryption. The followings describe about the new TDE design when we > > > choose table-level encryption or something-new-group-level encryption. > > > > > > General > > > ======== > > > We will use AES and support both AES-128 and AES-256. User can specify > > > the new initdb option something like --aes-128 or --aes-256 to enable > > > encryption and must specify --encryption-key-passphrase-command along > > > with. (I guess we also require openssl library.) If these options are > > > specified, we write the key length to the control file and derive the > > > KEK and generate MDEK during initdb. wal_log_hints will be enabled > > > automatically in encryption mode, like we do for checksum mode, > > > > Agreed. pg_control will store the none/AES128/AES256 indicator. > > > > > Key Management > > > ============== > > > We will use 3-tier key architecture as Joe proposed. > > > > > > 1. A master key encryption key (KEK): this is the ley supplied by the > > > database admin using something akin to ssl_passphrase_command > > > > > > 2. A master data encryption key (MDEK): this is a generated key using a > > > cryptographically secure pseudo-random number generator. It is > > > encrypted using the KEK, probably with Key Wrap (KW): > > > or maybe better Key Wrap with Padding (KWP): > > > > > > 3a. Per table data encryption keys (TDEK): use MDEK and HKDF to generate > > > table specific keys. > > > > What is the value of a per-table encryption key? How is HKDF derived? > > Per-table encryption key is derived from MDEK with salt and its OID as > info. I think we can store salts for each encryption keys into the > separate file so that off-line tool also can read it.
Thanks. I just sent an email with five possible options for this. I think relfilenode will be fine --- I am not sure what salt adds to this. > > Are we still unclear if the 68GB limit is per encryption key or per > > encryption key/IV combination? > > I think that 68GB refers to key+IV but I'll research that. Yes, please. I think we need a definite answer on that question, which you will see in my later email. > > I don't remember anyone suggesting different keys for different tables. > > How would this even be managed by the user? > > I think it's still unclear whether we implement one key for whole > database cluster or different keys for different table as the first > version. I'm evaluating the performance overhead of the latter that > you concerned and will share it. I am not worried about the performance of this --- if it not secure with a single key, it is useless, so we have to do it. If the single key is secure, I don't think multiple keys helps us. I think we already decided that the keys always have to be online for crash recovery, so we can't allow users to control their keys anyway. > I prefer tablespace-level or something-new-group-level than > table-level but if we choose the latter we can create a new group of > tables that are encrypted with the same key. That is user create a > group and then associate tables to that group. Tablespace-level is > implemented in the patch I submitted before. Or it's just idea but > another idea could be to allow users to create encryption key object > first and then specify which tables are encrypted with which > encryption key in DDL. For example, user creates an encryption keys > with name by SQL function and creates an encrypted table by CREATE > TABLE ... WITH (encryption_key = 'mykey');. That seems very complex so I think we need agreement to go in that direction, and see what I said above about multiple keys. > > That handles changing the passphrase, but what about rotating the > > encryption key? Don't we want to support that, at least in offline > > mode? > > Yeah, supporting rotating the encryption key is a good idea. Agreed. > > After more thoughts, it's a just idea but I wonder if the first > implementation step of TDE for v13 could be key management module. > That is, (in 3-tier case) PostgreSQL gets KEK by passphrase command or > directly, and creates MDEK. User can create an encryption key with > name using by SQL function, and the key manager derives DEK and store > its salt to the disk. Also we have an internal interface to get an > encryption key. > > The good point is not only to develop incrementally but also that if > PostgreSQL is able to manage (symmetric) encryption keys inside > database cluster and has interfaces to get and add keys, pgcrypt also > will be able to use it. That way, we will provide column-level TDE > first by combination of pgcrypt, triggers and views while keeping > encryption keys truly secret. After that we can add other level TDE > using the key management module. We would then be able to focus on how > to encrypt buffer and WAL. Uh, remember, all keys have to be online all the time, so what value does this add? -- 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 +