Re: storing an explicit nonce

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: storing an explicit nonce
Дата
Msg-id CA+TgmoaZYvGB9Aw6pFx2=dLzgrM5bGWTAG4vP=DPJQbmfkb2Bg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3.
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: storing an explicit nonce