Re: storing an explicit nonce - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: storing an explicit nonce
Date
Msg-id 20211007155023.GC20998@tamriel.snowman.net
Whole thread Raw
In response to Re: storing an explicit nonce  (Robert Haas <robertmhaas@gmail.com>)
Responses better page-level checksums  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: dfmgr additional ABI version fields
Next
From: Bruce Momjian
Date:
Subject: Re: storing an explicit nonce