> Content of some WAL records can be almost completely predicated (it > contains no user data, > just some Postgres internal data which can be easily reconstructed). > I wonder if this fact can significantly simplify task of cracking cypher?
AES is designed to resist known plaintext attacks, this isn't an issue as long as the code doesn't reuse the same IV twice. The example code uses a random iv for each WAL record, so that's unlikely. This is a quite nice solution to keep the encryption of WAL as parallel as possible. The downside is that it increases the size of WAL a bit, uses MemoryContextAllowInCriticalSection, and this approach is definitely slower during recovery than full page decryption. On the other hand, per page WAL encryption can cause performance issues with some workloads that write huge amounts of WAL with many parallel clients. Both have pros and cons. One thing that seems tricky is wal key rotation. The example code ignores this, which is fine for a demo, but real extensions should be able to handle it. We can't simply write a wal record about changing the wal key, because without holding the write lock things could get written out of order. The only safe solution I see is to also add the id of the wal key to the additional wal record data, increasing the record size even more.
