Re: storing an explicit nonce

On Thu, May 27, 2021 at 11:12 PM Bruce Momjian <bruce(at)momjian(dot)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.