On Thu, Jul 25, 2019 at 08:44:40PM -0400, Sehrope Sarkuni wrote: > On Thu, Jul 25, 2019 at 7:51 PM Bruce Momjian <br...@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.
I thought if we didn't have to hash the stuff together we would be less likely to get collisions with the IV. -- Bruce Momjian <br...@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 +
