On Thu, Jul 25, 2019 at 7:51 PM Bruce Momjian <bruce@momjian.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.
