Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Mar 21, 2019 at 7:46 AM Antonin Houska <a...@cybertec.at> wrote: > > Nevertheless, with the current version of our patch, PG should be resistant > > against such a partial write anyway because we chose to align XLOG records > > to > > 16 bytes (as long as the encryption is enabled) for the following reasons: > > > > If one XLOG record ends and the following one starts in the same encryption > > block, both records can get corrupted during streaming replication. The > > scenario looks like: 1) the first record is written on master (the unused > > part > > of the block contains zeroes), 2) the block is encrypted and its initial > > part > > (i.e. the number of bytes occupied by the first record in the plain text) is > > streamed to slave, 3) the second record is written on master, 4) the > > containing encryption block is encrypted again and the trailing part (i.e. > > the > > number of bytes occupied by the second record) is streamed, 5) decryption of > > the block on slave will produce garbage and thus corrupt both records. This > > is > > because the trailing part of the block was filled with zeroes during > > encryption, but it contains different data at decryption time. > > Wouldn't Tom's proposal to use a stream cipher fix all this?
Yes it would make the extra alignment unnecessary, but our solution tries to meet specific requirements of disk encryption. Stream cipher appears to be incompatible with these requirements: https://en.wikipedia.org/wiki/Disk_encryption_theory Currently we try to use the CBC-ESSIV mode. It's worth to mention that in this mode, if the page is encrypted twice and if the plain data in the encryption block N (i.e. block of 16 bytes) changes before the 2nd encryption, the encrypted data will only change in blocks >= N. So the problem of losing already flushed WAL records should not happen. -- Antonin Houska Web: https://www.cybertec-postgresql.com
