Re: storing an explicit nonce

On Thu, May 27, 2021 at 4:04 PM Andres Freund <andres(at)anarazel(dot)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