Horton

Re: storing an explicit nonce

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Kincaid <tomjohnkincaid@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Development <pgsql-hackers@postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Date: 2021-05-27T19:48:09Z
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 Thu, May 27, 2021 at 1:07 PM Andres Freund <andres@anarazel.de> wrote:
> But won't we then end up with a different set of requirements around
> nonce assignment durability when introducing GCM support? That's not
> actually entirely trivial to do correctly on a standby. I guess we can
> use AES-GCM-SSIV and be ok with living with edge cases leading to nonce
> reuse, but ...

All these different encryption modes are hard for me to grok.

That said, I want to mention a point which I think may be relevant
here. As far as I know, in the case of a permanent table page, we
never write X then X' then X again. If the change is WAL-logged, then
the LSN advances, and it will never thereafter go backward. Otherwise,
it's something that uses MarkBufferDirtyHint(). As far as I know, all
of those changes are one-way. For example, we set hint bits without
logging the change, but anything that clears hint bits is logged. We
mark btree index items dead as a type of hint, but they never come
back to life again; instead, they get cleaned out of the page entirely
as a WAL-logged operation. So I don't know that an adversary seeing
the same exact ciphertext multiple times is really likely to occur.

Well, it could certainly occur for temporary or unlogged tables, since
those have LSN = 0. And in cases were we currently copy pages around,
like creating a new database, it could happen. I suspect those cases
could be fixed, if we cared enough, and there are independent reasons
to want to fix the create-new-database case. It would be fairly easy
to put fake LSNs in temporary buffers, since they're in a separate
pool of buffers in backend-private memory with a separate buffer
manager. And it could probably even be done for unlogged tables,
though not as easily. Or we could use the special-space technique to
put some unpredictable garbage into each page and then change the
garbage every time we write the page. I read the discussion so far to
say that maybe these kinds of measures aren't even needed, and if so,
great. But even without doing anything, I don't think it's going to
happen very much.

Another case where this sort of thing might happen is a standby doing
whatever the master did. I suppose that could be avoided if the
standby always has its own encryption keys, but that forces a key
rotation when you create a standby, and it doesn't seem like a lot of
fun to insist on that. But the information leak seems minor. If we get
to a point where an adversary with full filesystem access on all our
systems can't do better than assessing our replication lag, we'll be a
lot better off then than we are now.

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