Re: storing an explicit nonce

Hi,

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.


> And in cases were we currently copy pages around, like creating a new
> database, it could happen.

As long as its identical data that should be fine, except leaking that
the data is identical. Which doesn't make me really concerned in case of
template databases.


> 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. [...] 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.

What precisely are you referring to with "aren't even needed"?

I don't see how the fake LSN approach can work for the crash recovery
issues?


> 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.


> 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).

Greetings,

Andres Freund