Bruce Momjian <br...@momjian.us> wrote: > On Tue, May 25, 2021 at 04:48:21PM -0700, Andres Freund wrote: > > Hi, > > > > On 2021-05-25 17:29:03 -0400, Bruce Momjian wrote: > > > So, let me ask --- I thought CTR basically took an encrypted stream of > > > bits and XOR'ed them with the data. If that is true, then why are > > > changing hint bits a problem? We already can see some of the bit stream > > > by knowing some bytes of the page. > > > > A *single* reuse of the nonce in CTR reveals nearly all of the > > plaintext. As you say, the data is XORed with the key stream. Reusing > > the nonce means that you reuse the key stream. Which in turn allows you > > to do: > > (data ^ stream) ^ (data' ^ stream) > > which can be simplified to > > (data ^ data') > > thereby leaking all of data except the difference between data and > > data'. That's why it's so crucial to ensure that stream *always* differs > > between two rounds of encrypting "related" data. > > > > We can't just "hope" that data doesn't change and use CTR. > > My point was about whether we need to change the nonce, and hence > WAL-log full page images if we change hint bits. If we don't and > reencrypt the page with the same nonce, don't we only expose the hint > bits? I was not suggesting we avoid changing the nonce in non-hint-bit > cases. > > I don't understand your computation above. You decrypt the page into > shared buffers, you change a hint bit, and rewrite the page. You are > re-XOR'ing the buffer copy with the same key and nonce. Doesn't that > only change the hint bits in the new write?
The way I view things is that the CTR mode encrypts each individual bit, independent from any other bit on the page. For non-hint bits data=data', so (data ^ data') is always zero, regardless the actual values of the data. So I agree with you that by reusing the nonce we only expose the hint bits. -- Antonin Houska Web: https://www.cybertec-postgresql.com
