Re: storing an explicit nonce

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Ants Aasma <ants(at)cybertec(dot)at>, Sasasu <i(at)sasa(dot)su>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: storing an explicit nonce
Date: 2021-10-12 14:26:54
Message-ID: CA+TgmoZknKf4b=WFh1RMWO=caGNK_zJR7s=zY9+LHdiEO7WfDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 7, 2021 at 11:05 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Sure, I get that. Would be awesome if all these things were clearly
> documented somewhere but I've never been able to find it quite as
> explicitly laid out as one would like.

:-(

> specifically: Appendix C: Tweaks
>
> Quoting a couple of paragraphs from that appendix:
>
> """
> In general, if there is information that is available and statically
> associated with a plaintext, it is recommended to use that information
> as a tweak for the plaintext. Ideally, the non-secret tweak associated
> with a plaintext is associated only with that plaintext.
>
> Extensive tweaking means that fewer plaintexts are encrypted under any
> given tweak. This corresponds, in the security model that is described
> in [1], to fewer queries to the target instance of the encryption.
> """
>
> The gist of this being- the more diverse the tweaking being used, the
> better. That's where I was going with my "limit the risk" comment. If
> we can make the tweak vary more for a given encryption invokation,
> that's going to be better, pretty much by definition, and as explained
> in publications by NIST.

I mean I don't have anything against that appendix, but I think we
need to understand - with confidence - what the expectations are
specifically around XTS, and that appendix seems much more general
than that.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-10-12 14:30:57 Re: pg14 psql broke \d datname.nspname.relname
Previous Message Robert Haas 2021-10-12 14:23:41 Re: pg14 psql broke \d datname.nspname.relname