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-25 23:48:21 |
Message-ID: | 20210525234821.y44vnbkdj66jhgn5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2021-05-25 23:48:54 | Re: storing an explicit nonce |
Previous Message | Andres Freund | 2021-05-25 23:35:42 | Re: storing an explicit nonce |