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? -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
