From: Eric Biggers <ebiggers@kernel.org>
To: Sandy Harris <sandyinchina@gmail.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH v2] random: mix build-time latent entropy into pool at init
Date: Mon, 4 Apr 2022 16:27:44 -0700 [thread overview]
Message-ID: <Ykt+8Fk9QP45XBmI@sol.localdomain> (raw)
In-Reply-To: <CACXcFm=vw6XCnO8peYH4V+sPR076O-Gav46r83+CZJ8oXM8iHA@mail.gmail.com>
On Sat, Apr 02, 2022 at 12:44:42PM +0800, Sandy Harris wrote:
> Yarrow is a good design, but it has limitations; in particular
> the Yarrow paper says the cryptographic strength is limited
> to the size of the hash context, 160 bits for their SHA-1 &
> 512 for our Blake.
>
> 512 bits is more than enough for nearly all use cases, but
> we may have some where it is not. How many random bits
> are needed to generate a 4k-bit PGP key?
>
> Will some users try to generate one-time pads from /dev/random?
> The OTP security proof requires truly random data as long as the
> message; with anything short of that the proof fails & you get
> a stream cipher.
All the data from /dev/{u,}random is generated by ChaCha20, which is a 256-bit
stream cipher. We don't target, or need to target, more than 256-bit security.
So the entropy pool itself doesn't need to be more than 256 bits, provided that
it is implemented properly using a cryptographic hash function, which it now is.
- Eric
prev parent reply other threads:[~2022-04-04 23:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-31 15:07 [PATCH] random: mix build-time latent entropy into pool at init Jason A. Donenfeld
2022-03-31 15:26 ` [PATCH v2] " Jason A. Donenfeld
2022-03-31 16:02 ` Michael Brooks
2022-03-31 18:21 ` Theodore Ts'o
2022-03-31 17:55 ` Theodore Ts'o
2022-04-02 4:44 ` Sandy Harris
2022-04-02 13:48 ` Jason A. Donenfeld
2022-04-04 23:27 ` Eric Biggers [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=Ykt+8Fk9QP45XBmI@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=sandyinchina@gmail.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.