On Thu, May 27, 2021 at 1:07 PM Andres Freund <and...@anarazel.de> wrote: > But won't we then end up with a different set of requirements around > nonce assignment durability when introducing GCM support? That's not > actually entirely trivial to do correctly on a standby. I guess we can > use AES-GCM-SSIV and be ok with living with edge cases leading to nonce > reuse, but ...
All these different encryption modes are hard for me to grok. 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. If the change is WAL-logged, then the LSN advances, and it will never thereafter go backward. Otherwise, it's something that uses MarkBufferDirtyHint(). As far as I know, all of those changes are one-way. For example, we set hint bits without logging the change, but anything that clears hint bits is logged. We mark btree index items dead as a type of hint, but they never come back to life again; instead, they get cleaned out of the page entirely as a WAL-logged operation. So I don't know that an adversary seeing the same exact ciphertext multiple times is really likely to occur. Well, it could certainly occur for temporary or unlogged tables, since those have LSN = 0. And in cases were we currently copy pages around, like creating a new database, it could happen. I suspect those cases could be fixed, if we cared enough, and there are independent reasons to want to fix the create-new-database case. It would be fairly easy to put fake LSNs in temporary buffers, since they're in a separate pool of buffers in backend-private memory with a separate buffer manager. And it could probably even be done for unlogged tables, though not as easily. 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. I read the discussion so far to say that maybe these kinds of measures aren't even needed, and if so, great. But even without doing anything, I don't think it's going to happen very much. 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. If we get to a point where an adversary with full filesystem access on all our systems can't do better than assessing our replication lag, we'll be a lot better off then than we are now. -- Robert Haas EDB: http://www.enterprisedb.com
