Re: storing an explicit nonce

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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-26 19:36:15
Message-ID: 20210526193615.GV3048@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 26, 2021 at 07:14:47AM +0200, Antonin Houska wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > On Tue, May 25, 2021 at 04:48:21PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2021-05-25 17:29:03 -0400, Bruce Momjian wrote:
> > > > So, let me ask --- I thought CTR basically took an encrypted stream of
> > > > bits and XOR'ed them with the data. If that is true, then why are
> > > > changing hint bits a problem? We already can see some of the bit stream
> > > > by knowing some bytes of the page.
> > >
> > > A *single* reuse of the nonce in CTR reveals nearly all of the
> > > plaintext. As you say, the data is XORed with the key stream. Reusing
> > > the nonce means that you reuse the key stream. Which in turn allows you
> > > to do:
> > > (data ^ stream) ^ (data' ^ stream)
> > > which can be simplified to
> > > (data ^ data')
> > > thereby leaking all of data except the difference between data and
> > > data'. That's why it's so crucial to ensure that stream *always* differs
> > > between two rounds of encrypting "related" data.
> > >
> > > We can't just "hope" that data doesn't change and use CTR.
> >
> > My point was about whether we need to change the nonce, and hence
> > WAL-log full page images if we change hint bits. If we don't and
> > reencrypt the page with the same nonce, don't we only expose the hint
> > bits? I was not suggesting we avoid changing the nonce in non-hint-bit
> > cases.
> >
> > I don't understand your computation above. You decrypt the page into
> > shared buffers, you change a hint bit, and rewrite the page. You are
> > re-XOR'ing the buffer copy with the same key and nonce. Doesn't that
> > only change the hint bits in the new write?
>
> The way I view things is that the CTR mode encrypts each individual bit,
> independent from any other bit on the page. For non-hint bits data=data', so
> (data ^ data') is always zero, regardless the actual values of the data. So I
> agree with you that by reusing the nonce we only expose the hint bits.

OK, that's what I thought. We already expose the clog and fsm, so
exposing the hint bits seems acceptable. If everyone agrees, I will
adjust my patch to not WAL log hint bit changes.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2021-05-26 19:47:34 Re: storing an explicit nonce
Previous Message Justin Pryzby 2021-05-26 19:32:38 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?