Re: storing an explicit nonce - Mailing list pgsql-hackers

From Andres Freund
Subject Re: storing an explicit nonce
Date
Msg-id 20210527170729.egdx6gxwgjjofmef@alap3.anarazel.de
Whole thread Raw
In response to Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Responses Re: storing an explicit nonce
Re: storing an explicit nonce
List pgsql-hackers
Hi,

On 2021-05-27 12:49:15 -0400, Stephen Frost wrote:
> That's not really a reason to rule it out though and Bruce's point about
> having a way to get to an encrypted cluster from an unencrypted one is
> certainly worth consideration.  Naturally, we'd need to document
> everything appropriately but there isn't anything saying that we
> couldn't, say, have XTS in v15 without any adjustments to the page
> layout, accepting that there's no data integrity validation and focusing
> just on encryption, and then returning to the question about adding in
> data integrity validation for a future version, perhaps using the
> special area for a nonce+tag with GCM or maybe something else.  Users
> who wish to move to a cluster with encryption and data integrity
> validation would have to get there through some other means than
> replication, but that's going to always be the case because we have to
> have space to store the tag, even if we can figure out some other
> solution for the nonce.

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

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: CREATE COLLATION - check for duplicate options and error out if found one
Next
From: John Naylor
Date:
Subject: Re: Reducing the range of OIDs consumed by genbki.pl