Re: storing an explicit nonce - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: storing an explicit nonce
Date
Msg-id 20210525212903.GM3048@momjian.us
Whole thread Raw
In response to Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Responses Re: storing an explicit nonce
Re: storing an explicit nonce
List pgsql-hackers
On Tue, May 25, 2021 at 05:22:43PM -0400, Stephen Frost wrote:
> * Bruce Momjian (bruce@momjian.us) wrote:
> > OK, this is good to know.  I know the never-reuse rule, so it is good to
> > know it can be relaxed for certain data without causing problems in
> > other places.  Should I modify my patch to do this?
> 
> Err, to be clear, I was saying that we could exclude the hint bits
> *entirely* from what's being encrypted and I don't think that would be a
> huge issue.  We still absolutely need to continue to implement a
> never-reuse rule when it comes to nonces and making sure that we don't
> encrypt different sets of data with the same key+nonce, it's just that
> if we exclude the hint bits from encryption then we don't need to worry
> about making sure to use a different nonce each time the hint bits
> change- because they're no longer relevant.

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.  I do think skipping encryption of
just the hint bits is more complex, so I want to understand why if is
needed.  (This is a question I eventually wanted to discuss, just like
my XXX questions.)

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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




pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: storing an explicit nonce
Next
From: Bruce Momjian
Date:
Subject: Re: storing an explicit nonce