From: "Theodore Ts'o" <tytso@mit.edu>
To: Sandy Harris <sandyinchina@gmail.com>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: random(4) question
Date: Thu, 20 Jan 2022 10:34:33 -0500 [thread overview]
Message-ID: <YemBCdWrGeKHWeFN@mit.edu> (raw)
In-Reply-To: <CACXcFm=67TU=wy-WdkpiGnSm2M-E5__z=ACTzCmOkiGijrWNOg@mail.gmail.com>
On Thu, Jan 20, 2022 at 06:39:31PM +0800, Sandy Harris wrote:
>
> Like the previous version based on SHA1, this produces an output half
> the hash size which is likely a fine idea since we do not want to
> expose the full hash output to an enemy. Unlike the older code,
> though, this does expose some hash output.
Well, as the comment says, we do this because we want to prevent
backtracking attacks --- where the attacker knows the state of the
pool plus the current outputs, and is trying to go back in time to
figure out previous outputs. Whether we XOR the halves together or
just reveal half the bits, either will achieve this goal.
Note that we're actually no longer directly exposing this output to
the enemy, since extract_buf is now only being use to extract entropy
from the input pool into the CRNG. And if the attacker can intercept
the values being used to reseed the CRNG, we've got bigger problems. :-)
Given how extrat_buf is being used today, assuming that we are
confident in the cryptosecurity of the CHACHA20 algorithm, it's
probably a bit of overkill as it is. However, it's not like this is
on the hot path from a performance perspective, and a bit of
over-engineering is not a bad thing.
Cheers,
- Ted
prev parent reply other threads:[~2022-01-20 15:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 10:39 random(4) question Sandy Harris
2022-01-20 10:44 ` Jason A. Donenfeld
2022-01-20 15:34 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YemBCdWrGeKHWeFN@mit.edu \
--to=tytso@mit.edu \
--cc=Jason@zx2c4.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=sandyinchina@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).