Re: storing an explicit nonce
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Ants Aasma <ants@cybertec.at>, Sasasu <i@sasa.su>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-07T15:50:23Z
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, * Robert Haas (robertmhaas@gmail.com) wrote: > On Wed, Oct 6, 2021 at 3:17 PM Stephen Frost <sfrost@snowman.net> wrote: > > With AES-XTS, we don't need to use the LSN as part of the nonce though, > > so I don't think this argument is actually valid..? As discussed > > previously regarding AES-XTS, the general idea was to use the path to > > the file and the filename itself plus the block number as the IV, and > > that works fine for XTS because it's ok to reuse it (unlike with CTR). > > However, there's also the option of storing a nonce in each page, as > suggested by the subject of this thread. I think that's probably a > pretty workable approach, as demonstrated by the patch that started > this thread. We'd need to think a bit carefully about whether any of > the compile-time calculations the patch moves to runtime are expensive > enough to matter and whether any such impacts can be mitigated, but I > think there is a good chance that such issues are manageable. I agree with this in general, though I would think we'd use that for GCM or another authenticated encryption mode (perhaps GCM-SIV with the LSN as the IV) at some point off in the future. Alternatively, we could use that technique to just provide a better per-page checksum than what we have today. Maybe we could figure out how to leverage that to move to 64bit transaction IDs with some page-level epoch. Definitely a lot of possibilities. Ultimately though, regarding TDE at least, I would think we'd rather start with something that's block level and doesn't require a page format change. > I'm a little concerned by the email from "Sasasu" saying that even in > XTS reusing the IV is not cryptographically weak. I don't know enough > about these different encryption modes to know if he's right, but if > he is then perhaps we need to consider his suggestion of using > AES-GCM. Or, uh, something else. Think you meant 'strong' above (or maybe omit the 'not', either way the oppostie of the double-negative that seems to be what was written). As I understand it, XTS isn't great for dealing with someone who has ongoing access to watch writes over time, just in general, but that wasn't what it is generally used to address (and isn't what we would be looking for it to address either). Perhaps there's other modes which don't require that we change the page format to support them besides XTS (in particular, as our pages are multiples of 16 bytes, it's possible we don't really need XTS since there aren't any partial blocks and could simply use XEX instead..) Thanks, Stephen