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

On Thu, Jul 25, 2019 at 7:51 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> Looking at the bits we have, the IV for AES is 16 bytes. Since we know
> we have to use LSN (to change the IV for each page write), and the page
> number (so WAL updates that change multiple pages with the same LSN use
> different IVs), that uses 12 bytes:
>
> LSN 8 bytes
> page-number 4 bytes
>
> That leaves 4 bytes unused. If we use CTR, we need 11 bits for the
> counter to support 32k pages sizes (per Sehrope Sarkuni), and we can use
> the remaining 5 bits as constants to indicate heap, index, or WAL.
> (Technically, since we are not encrypting the first 16 bytes, we could
> use one less bit for the counter.) If we also use relfilenode, that is
> 4 bytes, so we have no bits for the heap/index/WAL constant, and no
> space for the CTR counter, meaning we would have to use CBC mode.
>

You can still use CTR mode and include those to make the key + IV unique by
adding them to the derived key rather than the IV.

The IV per-page would still be LSN + page-number (with the block number
added as it's evaluated across the page) and the relfilenode, heap/index,
database, and anything else to make it unique can be included in the HKDF
to create the per-file derived key.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/