On Thu, May 27, 2021 at 4:04 PM Andres Freund <and...@anarazel.de> wrote: > On 2021-05-27 15:48:09 -0400, Robert Haas wrote: > > That said, I want to mention a point which I think may be relevant > > here. As far as I know, in the case of a permanent table page, we > > never write X then X' then X again. > > Well, there's crash recovery / restarts. And as previously explained > they can end up with different page contents than before.
Right, I'm not trying to oversell this point ... if in system XYZ there's a serious security exposure from ever repeating a page write, we should not use system XYZ unless we do some work to make sure that every page write is different. But if we just think it would be nicer if page writes didn't repeat, that's probably *mostly* true today already. > I don't see how the fake LSN approach can work for the crash recovery > issues? I wasn't trying to say it could. You've convinced me on that point. > > Or we could use the special-space technique to put some unpredictable > > garbage into each page and then change the garbage every time we write > > the page > > Unfortunately with CTR mode that doesn't provide much protection, if > it's part of the encrypted data (vs IV/nonce). A one bit change in the > encrypted data only changes one bit in the unencrypted data, as the data > is just XORd with the cipher stream. So random changes in one place > doesn't prevent disclosure in other parts of the data if the nonce > doesn't also change. And one can easily predict the effect of flipping > certain bits. Yeah, I wasn't talking about CTR mode there. I was just saying if we wanted to avoid ever repeating a write. > > Another case where this sort of thing might happen is a standby doing > > whatever the master did. I suppose that could be avoided if the > > standby always has its own encryption keys, but that forces a key > > rotation when you create a standby, and it doesn't seem like a lot of > > fun to insist on that. But the information leak seems minor. > > Which leaks seem minor? The "hole" issues leak all the prior contents of > the hole, without needing any complicated analysis of the data, because > one plain text is known (zeroes). No. You're confusing what I was saying here, in the contents of your comments about the limitations of AES-GCM-SIV, with the discussion with Bruce about nonce generation. -- Robert Haas EDB: http://www.enterprisedb.com