Re: storing an explicit nonce
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Kincaid <tomjohnkincaid@gmail.com>, Andres Freund <andres@anarazel.de>, Amit Kapila <amit.kapila16@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Date: 2021-05-26T01:42:48Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rethink method for assigning OIDs to the template0 and postgres DBs.
- 2cb1272445d2 15.0 landed
-
pg_upgrade: Preserve database OIDs.
- aa01051418f1 15.0 landed
-
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
- 9a974cbcba00 15.0 landed
-
Fix for new Boolean node
- cf925936ecc0 15.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Add macro RelationIsPermanent() to report relation permanence
- 95d77149c535 14.0 landed
-
Enhance nbtree index tuple deletion.
- d168b666823b 14.0 cited
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