Re: storing an explicit nonce

Greetings,

On Tue, May 25, 2021 at 14:56 Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Tue, May 25, 2021 at 02:25:21PM -0400, Robert Haas wrote:
> > One question here is whether we're comfortable saying that the nonce
> > is entirely constant. I wasn't sure about that. It seems possible to
> > me that different encryption algorithms might want nonces of different
> > sizes, either now or in the future. I am not a cryptographer, but that
> > seemed like a bit of a limiting assumption. So Bharath and I decided
> > to make the POC cater to a fully variable-size nonce rather than
> > zero-or-some-constant. However, if the consensus is that
> > zero-or-some-constant is better, fair enough! The patch can certainly
> > be adjusted to cater to work that way.
>
> A 16-byte nonce is sufficient for AES and I doubt we will need anything
> stronger than AES256 anytime soon. Making the nonce variable length
> seems it is just adding complexity for little purpose.

I’d like to review this more and make sure using the special space is
possible but if it is then it opens up a huge new possibility that we could
use it for both the nonce AND an appropriately sized tag, giving us
integrity along with encryption which would be a very significant
additional feature. I’d considered using a fork instead but having it on
the page would be far better.

I’ll also note that we could consider possibly even find an alternative use
for the space used for checksums, or leave them as they are today, though
they’d be redundant at that point to the tag.

Lastly, if the special space is actually able to be variable in size and we
could, say, store a flag in pg_class which tells us what’s in the special
space, then we could possibly give users the option of including the tag on
each page, or the choice of the size of tag, or possibly for other
interesting things in the future outside of encryption and data integrity.

Overall, I’m quite interested in the idea of making the special space able
to be variable. I do accept that will make it so it’s not possible to do
things like have physical replication between an unencrypted cluster and an
encrypted one, but the advantages seem worthwhile and users would still be
able to leverage logical replication to perform such a migration with
relatively little downtime.

Thanks!

Stephen

>