From: "H. Peter Anvin" <hpa@zytor.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
joern@logfs.org, macro@linux-mips.org, ralf@linux-mips.org,
dave.taht@gmail.com, blogic@openwrt.org, andrewmcgr@gmail.com,
smueller@chronox.de, geert@linux-m68k.org, tg@mirbsd.de
Subject: Re: [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded
Date: Sun, 22 Sep 2013 17:26:14 -0700 [thread overview]
Message-ID: <523F8AA6.7040406@zytor.com> (raw)
In-Reply-To: <20130922232337.GD7321@thunk.org>
On 09/22/2013 04:23 PM, Theodore Ts'o wrote:
> On Sun, Sep 22, 2013 at 03:45:11PM -0700, H. Peter Anvin wrote:
>> I understand the motivation, but I question basing it in a fixed amount of time.
>
> We already have a threshold based on the amount of the entropy in the
> input pool. I could increase that threshold, but then instead of
> having the entropy hover between say, 192 and 128, it would hover
> between say, 576 and 512. What that means in practice is that there
> will be a higher baseline, but we will still end up reseeding every 10
> seconds or so (that being approximately how much entropy I've seen
> flowing into the input pool on my laptop system --- 64 bits every 10
> seconds or so).
>
> By basing it on a time-based threshold, it means that the input pool
> can build up faster such that over time, such that entropy pool ends
> up hovering around 3400 bits.
>
So make it a threshold around 2048-3072 bits. A.k.a. "if the input pool
is filling up fast enough, take advantage of it."
> What is your concern is about having it being time-based --- or more
> accurately, being partially time-based, since we also keep the entorpy
> count based threshold? I'll note that the Fortuna Random Number
> Generator, devised by Bruce Schneier and Niels Ferguson also uses as
> part of its design a time-based reseed limit.
Just that it is unnecessary in a scenario when entropy is plentiful.
-hpa
next prev parent reply other threads:[~2013-09-23 0:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-22 20:38 [PATCH, RFC 00/12] random driver changes Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 01/12] random: run random_int_secret_init() run after all late_initcalls Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 02/12] random: Statically compute poolbitshift, poolbytes, poolbits Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 03/12] random: Allow fractional bits to be tracked Theodore Ts'o
2013-09-23 4:01 ` Theodore Ts'o
2013-09-23 4:03 ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 04/12] random: Account for entropy loss due to overwrites Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 05/12] random: fix the tracepoint for get_random_bytes(_arch) Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 06/12] random: optimize spinlock use in add_device_randomness() Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 07/12] random: allow architectures to optionally define random_get_entropy() Theodore Ts'o
2013-09-23 10:38 ` Stephan Mueller
2013-09-23 11:05 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf() Theodore Ts'o
2013-09-23 4:11 ` H. Peter Anvin
2013-09-23 4:33 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 09/12] random: optimize the entropy_store structure Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded Theodore Ts'o
2013-09-22 21:21 ` H. Peter Anvin
2013-09-22 21:40 ` Theodore Ts'o
2013-09-22 22:45 ` H. Peter Anvin
2013-09-22 23:23 ` Theodore Ts'o
2013-09-23 0:26 ` H. Peter Anvin [this message]
2013-09-22 20:38 ` [PATCH, RFC 11/12] random: speed up the fast_mix function by a factor of four Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 12/12] random: adjust the generator polynomials in the mixing function slightly Theodore Ts'o
2013-09-25 10:51 ` Jörg-Volker Peetz
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=523F8AA6.7040406@zytor.com \
--to=hpa@zytor.com \
--cc=andrewmcgr@gmail.com \
--cc=blogic@openwrt.org \
--cc=dave.taht@gmail.com \
--cc=geert@linux-m68k.org \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=smueller@chronox.de \
--cc=tg@mirbsd.de \
--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.