Re: storing an explicit nonce

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
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-07T14:28:55Z
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 →
  1. Rethink method for assigning OIDs to the template0 and postgres DBs.

  2. pg_upgrade: Preserve database OIDs.

  3. pg_upgrade: Preserve relfilenodes and tablespace OIDs.

  4. Fix for new Boolean node

  5. Improve error handling of HMAC computations

  6. Add macro RelationIsPermanent() to report relation permanence

  7. Enhance nbtree index tuple deletion.

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'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.

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