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

From Bruce Momjian
Subject Re: storing an explicit nonce
Date
Msg-id 20210526013359.GQ3048@momjian.us
Whole thread Raw
In response to Re: storing an explicit nonce  (Stephen Frost <sfrost@snowman.net>)
Responses Re: storing an explicit nonce
List pgsql-hackers
On Tue, May 25, 2021 at 07:48:54PM -0400, Stephen Frost wrote:
> Greetings,
> 
> * Bruce Momjian (bruce@momjian.us) wrote:
> > 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.)
> 
> That's how CTR works, yes.  The issue that you run into is that once
> you've got two pages which have different data but were encrypted with
> the same key and nonce then you can use crib-dragging.
> 
> A good example of how this works is here:
> 
> http://travisdazell.blogspot.com/2012/11/many-time-pad-attack-crib-drag.html
> 
> Once you've got the two different pages which had the same key+nonce
> used, you can XOR them together and then start cribbing, scanning the
> page for legitimate data which doesn't have to be in the part of the
> data that was different between the two original pages.
> 
> Not sure what you're referring to in the second half ... simply knowing
> that some of the data has a given plaintext (such as having a really
> good idea that the word 'the' exists in a given message) doesn't provide
> you the same level of information as two pages encrypted with the same
> key+nonce but having different data.  Indeed, AES is generally believed
> to be quite effective against even given plaintext attacks:
> 
>
https://math.stackexchange.com/questions/51960/is-it-possible-to-guess-an-aes-key-from-a-series-of-messages-encrypted-with-that/57428

Agreed.  I was just reinforcing that, and trying to say that hint bit
change might also be considered known information.

Anyway, if you think the hint bit changes would leak, I an accept that. 
It means we need to wal log hit bit changes, no matter if the nonce is
the LSN or a custom one.

-- 
  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: Justin Pryzby
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Next
From: Michael Paquier
Date:
Subject: Incorrect GUC descriptions in docs and postgresql.conf.sample