Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, May 25, 2021 at 07:48:54PM -0400, Stephen Frost wrote:
> > Not sure what you're referring to in the second half ... simply knowing
> > that some of the data has a given plaintext (such as having a really
> > good idea that the word 'the' exists in a given message) doesn't provide
> > you the same level of information as two pages encrypted with the same
> > key+nonce but having different data. Indeed, AES is generally believed
> > to be quite effective against even given plaintext attacks:
> >
> >
https://math.stackexchange.com/questions/51960/is-it-possible-to-guess-an-aes-key-from-a-series-of-messages-encrypted-with-that/57428
>
> Agreed. I was just reinforcing that, and trying to say that hint bit
> change might also be considered known information.
>
> Anyway, if you think the hint bit changes would leak, I an accept that.
> It means we need to wal log hit bit changes, no matter if the nonce is
> the LSN or a custom one.
The nonce needs to be a new one, if we include the hint bits in the set
of data which is encrypted.
However, what I believe folks are getting at here is that we could keep
the LSN the same, but increase the nonce when the hint bits change, but
*not* WAL log either the nonce change or the hint bit change (unless
it's being logged for some other reason, in which case log both), thus
reducing the amount of WAL being produced. What would matter is that
both the hint bit change and the new nonce hit disk at the same time, or
neither do, or we replay back to some state where the nonce and the hint
bits 'match up' so that the page decrypts (and the integrity check
works).
That generally seems pretty reasonable to me and basically makes the
increase in nonce work very much in the same manner that the hint bits
themselves do- sometimes it changes even when the LSN doesn't but, in
such cases, we don't actually WAL it, and that's ok because we don't
actually care about it being updated- what's in the WAL when the page is
replayed is perfectly fine and we'll just update the hint bits again
when and if we decide we need to based on the actual visibility
information at that time.
Now, making sure that we don't end up re-using the same nonce over again
is a concern and we'd want to address that somehow, as suggested
earlier perhaps by simply incrementing it making sure to durably note
whenever we'd crossed some threshold (each 1k or whatever) and then on
crash recovery making sure we bump past that, but that seems entirely
doable.
Thanks,
Stephen
