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

From Robert Haas
Subject Re: storing an explicit nonce
Date
Msg-id CA+TgmoaZYvGB9Aw6pFx2=dLzgrM5bGWTAG4vP=DPJQbmfkb2Bg@mail.gmail.com
Whole thread Raw
In response to Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Responses Re: storing an explicit nonce
List pgsql-hackers
On Thu, Oct 7, 2021 at 3:38 PM Stephen Frost <sfrost@snowman.net> wrote:
> While I certainly also appreciate that we want to get this as right as
> we possibly can from the start, I strongly suspect we'll have one of two
> reactions- either we'll be more-or-less ignored and it'll be crickets
> from the security folks, or we're going to get beat up by them for
> $reasons, almost regardless of what we actually do.  Best bet to
> limit the risk ( ;) ) of the latter happening would be to try our best
> to do what existing solutions already do- such as by using XTS.
> There's things we can do to limit the risk of known-plaintext attacks,
> like simply not encrypting empty pages, or about possible known-IV
> risks, like using the LSN as part of the IV/tweak.  Will we get
> everything?  Probably not, but I don't think that we're going to really
> go wrong by using XTS as it's quite popularly used today and it's
> explicitly used for cases where you haven't got a place to store the
> extra nonce that you would need for AEAD encryption schemes.

I agree that using a popular approach is a good way to go. If we do
what other people do, then hopefully our stuff won't be significantly
more broken than their stuff, and whatever is can be fixed.

> As long as we're clear that this initial version of TDE is with XTS then
> I really don't think we'll end up with anyone showing up and saying we
> screwed up by not generating a per-page nonce to store with it- the point
> of XTS is that you don't need that.

I agree that we shouldn't really catch flack for any weaknesses of the
underlying algorithm: if XTS turns out to be secure even when used
properly, and we use it properly, the resulting weakness is somebody
else's fault. On the other hand, if we use it improperly, that's our
fault, so we need to be really sure that we understand what guarantees
we need to provide from our end, and that we are providing them. Like
if we pick an encryption mode that requires nonces to be unique, we
will be at fault if they aren't; if it requires nonces to be
unpredictable, we will be at fault if they aren't; and so on.

So that's what is making me nervous here ... it doesn't seem likely we
have complete unanimity about whether XTS is the right thing, though
that does seem to be the majority position certainly, and it is not
really clear to me that any of us can speak with authority about what
the requirements are around the nonces in particular.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3.
Next
From: Stephen Frost
Date:
Subject: Re: storing an explicit nonce