Re: storing an explicit nonce

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Subject: Re: storing an explicit nonce
Date: 2021-05-27 15:10:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, May 26, 2021 at 05:11:24PM -0700, Andres Freund wrote:
> Hi,
> 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.

Bruce Momjian <bruce(at)momjian(dot)us>

If only the physical world exists, free will is an illusion.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-05-27 15:12:17 Re: storing an explicit nonce
Previous Message Bruce Momjian 2021-05-27 15:10:00 Re: storing an explicit nonce