Horton

Re: storing an explicit nonce

Neil Chen <carpenter.nail.cz@gmail.com>

View thread
From: Neil Chen <carpenter.nail.cz@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, 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-28T06:12:53Z
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 11:12 PM Bruce Momjian <bruce@momjian.us> wrote:

>
> Well, the code now does write full page images for hint bit changes, so
> it should work fine.
>
>
Yes, indeed it works well and I'd tested it. But here I want to make clear
my understanding of the argument, if there is any problem please help me
correct it.

1. Why couldn't we just throw away the hint bit change? Just don't encrypt
them?
Maybe we can expose the *pd_flags*, we needn't re-encrypt when it
changed and there's no security risk. But there have many other changes
that will call the function *MarkBufferDirtyHint* and we also needn't WAL
log them too. We couldn't expose all of them, so the way "throw them away,
don't encrypt them" is not feasible.

2. Why can we accept the performance degradation caused by checksum in this
way, but TDE can't?
The checksum must be implemented in this way, but in TDE maybe we can try
another way to avoid this harm.

3. Another benefit of using the special space is that it's also can be used
for AES-GCM to support integrity.

I'm just a beginner of PG and may not have considered some obvious
problems. But please let me put forward my rough idea again -- Why can't we
simply use LSN+blockNum+checksum as nonce?
When the checksums are enabled, every time we call the
*MarkBufferDirtyHint* will generate a new LSN. So we can simply use the
LSN+blockNum+0000 as the nonce.
When the checksums are disabled, we can use these unused checksum values as
a counter to make sure we have different nonce even if we don't write the
new WAL record.

-- 
There is no royal road to learning.
HighGo Software Co.