Re: storing an explicit nonce

Hi,

On 2021-05-27 11:49:33 -0400, Stephen Frost wrote:
> * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > On Thu, May 27, 2021, at 08:10, Bruce Momjian wrote:
> > > On Wed, May 26, 2021 at 05:11:24PM -0700, Andres Freund wrote:
> > > > On 2021-05-25 17:12:05 -0400, Bruce Momjian wrote:
> > > > > If we used a block cipher instead of a streaming one (CTR), this might
> > > > > not work because the earlier blocks can be based in the output of
> > > > > later blocks.
> > > >
> > > > What made us choose CTR for WAL & data file encryption? I checked the
> > > > README in the patchset and the wiki page, and neither seem to discuss
> > > > that.
> > > >
> > > > The dangers around nonce reuse, the space overhead of storing the nonce,
> > > > the fact that single bit changes in the encrypted data don't propagate
> > > > seem not great? Why aren't we using something like XTS? It has obvious
> > > > issues as wel, but CTR's weaknesses seem at least as great. And if we
> > > > want a MAC, then we don't want CTR either.
> > >
> > > We chose CTR because it was fast, and we could use the same method for
> > > WAL, which needs a streaming, not block, cipher.
> >
> > The WAL is block oriented too.
>
> I'm curious what you'd suggest for the heap where we wouldn't be able to
> have block chaining (at least, I presume we aren't talking about
> rewriting entire segments whenever we change something in a heap).

What prevents us from using something like XTS? I'm not saying that that
is the right approach, due to the fact that it leaks information about a
block being the same as an earlier version of the same block. But right
now we are talking about using CTR without addressing the weaknesses CTR
has, where a failure to increase the nonce is fatal (the code even
documents known cases where that could happen!), and where there's no
error propagation within a block.

Greetings,

Andres Freund