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