|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Simon Josefsson <simon@josefsson.org> To: David Wagner <daw@cs.berkeley.edu> Cc: cryptography@metzdowd.com Date: Mon, 18 Feb 2008 12:05:49 +0100 In-Reply-To: <200802132149.m1DLndsV003526@taverner.cs.berkeley.edu> (David Wagner's message of "Wed, 13 Feb 2008 13:49:39 -0800 (PST)") David Wagner <daw@cs.berkeley.edu> writes: > Crawford Nathan-HMGT87 writes: >>One of the problems with the Linux random number generator >>is that it happens to be quite slow, especially if you need a lot of >>data. > > /dev/urandom is blindingly fast. For most applications, that's > all you need. Alas, reading from /dev/urandom depletes the entropy pool much like reading from /dev/random does. So if you read a lot of data from /dev/urandom, you make /dev/random unusable in practice. This problem has hit libgcrypt/gnutls via the MTA Exim on a lot of Debian systems. I would argue that the linux kernel /dev/*random system is sub-optimally designed, reading a lot of data from /dev/urandom should not cause the system's /dev/random to be unusable. (Admittedly, there were other design flaws in how exim used gnutls, such as re-generating the DH parameters every X hour, and doing that synchronously in the SMTP process, causing them all to stall waiting for entropy, but that has been fixed.) /Simon --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |