On Tue, May 25, 2021 at 03:20:06PM -0400, Bruce Momjian wrote: > Also, when you change hint bits, either you don't change the nonce/LSN, > and don't re-encrypt the page (and the hint bit changes are visible), or > you change the nonce and reencrypt the page, and you are then WAL > logging the page. I don't see how having a nonce different from the LSN > helps here.
Let me go into more detail here. The general rule is that you never encrypt _different_ data with the same key/nonce. Now, since a hint bit change changes the data, it should get a new nonce, and since it is a newly encrypted page (using a new nonce), it should be WAL logged because a torn page would make the data unreadable. Now, if we want to consult some security experts and have them tell us the hint bit visibility is not a problem, we could get by without using a new nonce for hint bit changes, and in that case it doesn't matter if we have a separate LSN or custom nonce --- it doesn't get changed for hint bit changes. My point is that we have to full-page-write cases where we change the nonce --- we get a new LSN/nonce for free if we are using the LSN as the nonce. What has made this approach much easier is that you basically tie a change of the nonce to require a change of LSN, since you are WAL logging it and every nonce change has to be full-page-write WAL logged. This makes the LSN-as-nonce less fragile to breakage than a custom nonce, in my opinion, which may explain why my patch is so small. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
