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

On Wed, Jul 31, 2019 at 09:43:00AM -0400, Sehrope Sarkuni wrote:
> On Wed, Jul 31, 2019 at 2:32 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> 
>     Just to confirm, we have 21 bits left for nonce in CTR? We have LSN (8
>     bytes), page-number (4 bytes) and counter (11 bits) in 16 bytes nonce
>     space. Even though we have 21 bits left we cannot store relfilenode to
>     the IV.
> 
> 
> Fields like relfilenode, database, or tablespace could be added to the derived
> key, not the per-page IV. There's no space limitations as they are additional
> inputs into the HKDF (key derivation function).

Yes, but we want to avoid that for other reasons.

>     For WAL encryption,  before flushing WAL we encrypt whole 8k WAL page
>     and then write only the encrypted data of the new WAL record using
>     pg_pwrite() rather than write whole encrypted page. So each time we
>     encrypt 8k WAL page we end up with encrypting different data with the
>     same key+nonce but since we don't write to the disk other than space
>     where we actually wrote WAL records it's not a problem. Is that right?
> 
> Ah, this is what I was referring to in my previous mail. I'm not familiar with
> how the writes happen yet (reading up...) but, yes, we would need to ensure
> that encrypted data is not written more than once (i.e. no writing of encrypt
> (zero) followed by writing of encrypt(non-zero) at the same spot).

Right.  The 8k page LSN changes each time the page is modified, and the
is part of the page nonce.

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