Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Antonin Houska <ah@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Toshi Harada <harada.toshi@po.ntt-tx.co.jp>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-03-21T20:07:15Z
Lists: pgsql-hackers
On Thu, Mar 21, 2019 at 7:46 AM Antonin Houska <ah@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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Dramatically reduce System V shared memory consumption.
- b0fc0df9364d 9.3.0 cited