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

On Tue, Jul 30, 2019 at 10:14:14AM -0400, Sehrope Sarkuni wrote:
>     > In general it's fine to use the same IV with different keys. Only reuse
>     of Key
>     > + IV is a problem and the entire set of possible counter values (IV + 0,
>     IV +
>     > 1, ...) generated with a key must be unique. That's also why we must
>     leave at
>     > least log2(PAGE_SIZE / AES_BLOCK_SIZE) bits at the end of the IV to be
>     filled
>     > in with 0, 1, 2, ... for each 16-byte AES-block on the page. If our
>     per-page IV
>     > prefix used any of those bits then the counter could overflow into the
>     next
>     > page's IV's range.
> 
>     Agreed.
> 
>     Attached is an updated patch that checks only main relation forks, which
>     I think are the only files we are going ot encrypt, and it has better
>     comments.
> 
> 
> Okay that makes sense in the context of using a single key and relying on the
> LSN based IV to be unique.

I had more time to think about the complexity of adding relfilenode to
the IV.  Since relfilenode is only unique within a database/tablespace,
we would need to have pg_upgrade preserve database/tablespace oids
(which I assume are the same as the directory and tablespace symlinks). 
Then, to decode a page, you would need to look up those values.  This is
in addition to the new complexity of CREATE DATABASE and moving files
between tablespaces.  I am also concerned that crash recovery operations
and cluster forensics and repair would need to also deal with this.

I am not even clear if pg_upgrade preserving relfilenode is possible ---
when we wrap the relfilenode counter, does it start at 1 or at the
first-user-relation-oid?  If the former, it could conflict with oids
assigned to new system tables in later major releases.  Tying the
preservation of relations to two restrictions seems risky.

Using just the page LSN and page number allows a page to be be
decrypted/encrypted independently of its file name, tablespace, and
database, and I think that is a win for simplicity.  Of course, if it is
insecure we will not do it.

I am thinking for the heap/index IV, it would be:

    uint64 lsn;
    unint32 page number;
    /* only uses 11 bits for a zero-based CTR counter for 32k pages */
    uint32 counter;

and for WAL it would be:

    uint64 segment_number;
    uint32    counter;
    /* guarantees this IV doesn't match any relation IV */
    uint32   2^32-1 /* all 1's */    

Anyway, these are my thoughts so far.

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