Re: storing an explicit nonce

From: Andres Freund <andres(at)anarazel(dot)de>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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 00:11:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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

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.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-05-27 00:13:30 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Previous Message Andres Freund 2021-05-26 23:46:29 Re: storing an explicit nonce