From: Bill Davidsen <davidsen@tmr.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Ray Lee <ray@madrabbit.org>, Adrian Bunk <bunk@kernel.org>,
Marc Haber <mh+linux-kernel@zugschlus.de>,
linux-kernel@vger.kernel.org
Subject: Re: Why does reading from /dev/urandom deplete entropy so much?
Date: Thu, 06 Dec 2007 15:08:30 -0500 [thread overview]
Message-ID: <475856BE.4050207@tmr.com> (raw)
In-Reply-To: <20071204180158.GT19691@waste.org>
Matt Mackall wrote:
> On Tue, Dec 04, 2007 at 08:54:52AM -0800, Ray Lee wrote:
>> (Why hasn't anyone been cc:ing Matt on this?)
>>
>> On Dec 4, 2007 8:18 AM, Adrian Bunk <bunk@kernel.org> wrote:
>>> On Tue, Dec 04, 2007 at 12:41:25PM +0100, Marc Haber wrote:
>>>
>>>> While debugging Exim4's GnuTLS interface, I recently found out that
>>>> reading from /dev/urandom depletes entropy as much as reading from
>>>> /dev/random would. This has somehow surprised me since I have always
>>>> believed that /dev/urandom has lower quality entropy than /dev/random,
>>>> but lots of it.
>>> man 4 random
>>>
>>>> This also means that I can "sabotage" applications reading from
>>>> /dev/random just by continuously reading from /dev/urandom, even not
>>>> meaning to do any harm.
>>>>
>>>> Before I file a bug on bugzilla,
>>>> ...
>>> The bug would be closed as invalid.
>>>
>>> No matter what you consider as being better, changing a 12 years old and
>>> widely used userspace interface like /dev/urandom is simply not an
>>> option.
>> You seem to be confused. He's not talking about changing any userspace
>> interface, merely how the /dev/urandom data is generated.
>>
>> For Matt's benefit, part of the original posting:
>>
>>> Before I file a bug on bugzilla, can I ask why /dev/urandom wasn't
>>> implemented as a PRNG which is periodically (say, every 1024 bytes or
>>> even more) seeded from /dev/random? That way, /dev/random has a much
>>> higher chance of holding enough entropy for applications that really
>>> need "good" entropy.
>> A PRNG is clearly unacceptable. But roughly restated, why not have
>> /dev/urandom supply merely cryptographically strong random numbers,
>> rather than a mix between the 'true' random of /dev/random down to the
>> cryptographically strong stream it'll provide when /dev/random is
>> tapped? In principle, this'd leave more entropy available for
>> applications that really need it, especially on platforms that don't
>> generate a lot of entropy in the first place (servers).
>
> The original /dev/urandom behavior was to use all the entropy that was
> available, and then degrade into a pure PRNG when it was gone. The
> intent is for /dev/urandom to be precisely as strong as /dev/random
> when entropy is readily available.
>
> The current behavior is to deplete the pool when there is a large
> amount of entropy, but to always leave enough entropy for /dev/random
> to be read. This means we never completely starve the /dev/random
> side. The default amount is twice the read wakeup threshold (128
> bits), settable in /proc/sys/kernel/random/.
>
In another post I suggested having a minimum bound (use not entropy) and
a maximum bound (grab some entropy) with the idea that between these
values some limited entropy could be used. I have to wonder if the
entropy available is at least as unpredictable as the entropy itself.
> But there's really not much point in changing this threshold. If
> you're reading the /dev/random side at the same rate or more often
> that entropy is appearing, you'll run out regardless of how big your
> buffer is.
>
Right, my thought is to throttle user + urandom use such that the total
stays below the available entropy. I had forgotten that that was a lower
bound, although it's kind of an on-off toggle rather than proportional.
Clearly if you care about this a *lot* you will use a hardware RNG.
Thanks for the reminder on read_wakeup.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
next prev parent reply other threads:[~2007-12-06 19:52 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-04 11:41 Why does reading from /dev/urandom deplete entropy so much? Marc Haber
2007-12-04 14:16 ` Eric Dumazet
2007-12-04 16:18 ` Adrian Bunk
2007-12-04 16:47 ` Alan Cox
2007-12-04 18:17 ` Eric Dumazet
2007-12-05 21:26 ` Matt Mackall
2007-12-06 7:02 ` Eric Dumazet
2007-12-06 16:09 ` Matt Mackall
2007-12-09 12:42 ` Marc Haber
2007-12-09 16:16 ` Matt Mackall
2007-12-10 23:06 ` Marc Haber
2007-12-10 23:35 ` Matt Mackall
2007-12-11 1:34 ` Theodore Tso
2007-12-11 19:46 ` Phillip Susi
2007-12-11 20:02 ` Ray Lee
2007-12-12 5:34 ` David Schwartz
2007-12-04 16:54 ` Ray Lee
2007-12-04 16:55 ` Alan Cox
2007-12-04 18:02 ` Matt Mackall
2007-12-04 19:50 ` Theodore Tso
2007-12-04 20:36 ` Matt Mackall
2007-12-04 20:40 ` Alan Cox
2007-12-04 20:48 ` Mike McGrath
2007-12-04 21:54 ` Matt Mackall
2007-12-04 22:03 ` Theodore Tso
2007-12-04 22:12 ` Mike McGrath
2007-12-04 22:28 ` Matt Mackall
2007-12-04 21:08 ` Matt Mackall
2007-12-04 21:18 ` Mike McGrath
2007-12-04 22:15 ` Matt Mackall
2007-12-04 22:23 ` Mike McGrath
2007-12-04 22:33 ` Matt Mackall
2007-12-05 14:26 ` Mike McGrath
2007-12-05 14:49 ` Theodore Tso
2007-12-08 7:38 ` Jon Masters
2007-12-08 17:32 ` Theodore Tso
2007-12-08 17:33 ` Mike McGrath
2007-12-08 17:49 ` Theodore Tso
2007-12-08 17:54 ` Jon Masters
2007-12-08 18:15 ` Matt Mackall
2007-12-08 18:24 ` Theodore Tso
2007-12-08 19:36 ` entropy gathering (was Re: Why does reading from /dev/urandom deplete entropy so much?) Jeff Garzik
2007-12-08 19:53 ` Matt Mackall
2007-12-08 20:04 ` Jeff Garzik
2007-12-08 20:19 ` Matt Mackall
2007-12-08 21:07 ` Willy Tarreau
2007-12-08 20:31 ` Theodore Tso
2007-12-08 20:47 ` Jeff Garzik
2007-12-08 20:42 ` Willy Tarreau
2007-12-08 23:47 ` Theodore Tso
2007-12-09 1:07 ` Jon Masters
2007-12-08 18:31 ` Why does reading from /dev/urandom deplete entropy so much? Jeff Garzik
2007-12-08 20:26 ` David Schwartz
2007-12-08 17:43 ` Matt Mackall
2007-12-08 17:47 ` Jon Masters
2007-12-08 18:05 ` Theodore Tso
2007-12-08 17:45 ` Jon Masters
2007-12-10 16:37 ` Pavel Machek
2007-12-04 18:01 ` Matt Mackall
2007-12-06 20:08 ` Bill Davidsen [this message]
2007-12-05 12:23 ` Marc Haber
2007-12-05 12:29 ` Marc Haber
2007-12-05 13:33 ` Theodore Tso
2007-12-05 15:10 ` Marc Haber
2007-12-06 19:32 ` Bill Davidsen
2007-12-08 22:03 ` Adrian Bunk
2007-12-08 22:10 ` Ismail Dönmez
2007-12-08 23:46 ` Theodore Tso
2007-12-09 5:21 ` Willy Tarreau
2007-12-09 6:52 ` Jon Masters
2007-12-09 6:21 ` Ismail Dönmez
2007-12-09 12:31 ` Theodore Tso
2007-12-09 14:06 ` Ismail Dönmez
2007-12-11 15:42 ` Bill Davidsen
2007-12-20 22:27 ` Marc Haber
2007-12-26 18:27 ` Phillip Susi
2007-12-04 18:49 ` Russ Dill
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=475856BE.4050207@tmr.com \
--to=davidsen@tmr.com \
--cc=bunk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mh+linux-kernel@zugschlus.de \
--cc=mpm@selenic.com \
--cc=ray@madrabbit.org \
/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).