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

From cary huang
Subject Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Date
Msg-id CALS+J3-57cL=jz_eT9uxiLa8CAh5BE3-HcQvXQBz0ScMjag4Zg@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Sehrope Sarkuni <sehrope@jackdb.com>)
List pgsql-hackers
On Mon, Jan 6, 2020 at 4:43 AM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote:
On Sat, 4 Jan 2020 at 15:11, cary huang <hcary328@gmail.com> wrote:
>>
>> Hello Sawada and all
>>
>> I would like to elaborate more on Sehrope and Sawada's discussion on passing NULL IV in "pg_cipher_encrypt/decrypt" functions during kmgr_wrap_key and kmgr_unwrap_key routines in kmgr_utils.c. Openssl implements key wrap according to RFC3394 as Sawada mentioned and passing NULL will make openssl to use default IV, which equals to A6A6A6A6A6A6A6A6. I have confirmed this on my side; A key wrapped with "NULL" IV can be unwrapped successfully with IV=A6A6A6A6A6A6A6A6, and unwrap will fail if IV is set to anything else other than NULL or A6A6A6A6A6A6A6A6.
>>

>Sehrope also suggested me not to use the fixed IV in order to avoid
>getting the same result from the same value. I'm researching it now.
>Also, currently it's using key wrap algorithm[1] but it accepts only
>multiple of 8 bytes as input. Since it's not good for some cases it's
>better to use key wrap with padding algorithm[2] instead, which seems
>available in OpenSSL 1.1.0 or later.

Since the current kmgr only supports AES128 and AES256, the master key generated by kmgr during bootstrap will always be multiple of 8. I believe AES keys in general must always be in multiple of 8. I have not done enough research as to which encryption algorithm will involve keys not in multiple of 8 so I think with the current key_wrap_algorithm is fine. With the key wrap algorithm defined in RFC3394. The IV is used only as a "initial value" and it has to be static; either we randomize one or we use the default A6A6A6... by passing NULL, It is different from the CTR block cipher mode which has been selected to encrypt WAL and buffer. In CTR mode, each block requires a different and unique IV as input in order to be secured; and we have agreed to use segment IDs as IVs. For this reason, I think the current key wrap implementation is fine. The least we can do is to generate a IV during bootstrap and store it in control file, and this generated IV will be used for all key wrapping / unwrapping purposes instead of using the default one.

Best regards
Cary Huang
HighGo Software Canada

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Setting min/max TLS protocol in clientside libpq
Next
From: Tom Lane
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files