SSL/TLS passive sniffing

[Florian Weimer]

* Victor Duchovni:

>> The Debian folks have recently stumbled upon a problem in this area:
>> Generating the ephemeral DH parameters is expensive, in terms of CPU
>> cycles, but especailly in PRNG entropy.  The PRNG part means that it's
>> not possible to use /dev/random on Linux, at least on servers.  The
>> CPU cycles spent on bignum operations aren't a real problem.
>> 
>> Would you recommend to switch to /dev/urandom (which doesn't block if
>> the entropy estimate for the in-kernel pool reaches 0), and stick to
>> generating new DH parameters for each connection, or is it better to
>> generate them once per day and use it for several connections?
>> 
>
> Actually reasoning along these lines is why Lutz Jaenicke implemented
> PRNGD, it is strongly recommended (at least by me) that mail servers
> use PRNGD or similar.  PRNGD delivers psuedo-random numbers mixing in
> real entropy periodically.
>
> EGD, /dev/random and /dev/urandom don't produce bits fast enough.

Is this the only criticism of /dev/urandom (on Linux, at least)?  Even
on ancient hardware (P54C at 200 MHz), I can suck about 150 kbps out
of /dev/urandom, which is more than enough for our purposes.  (It's
not a web server, after all.)

I'm slightly troubled by claims such as this one:

  <http://lists.debian.org/debian-devel/2004/12/msg01950.html>

I know that Linux' /dev/random implementation has some problems (I
believe that the entropy estimates for mouse movements are a bit
unrealistic, somewhere around 2.4 kbps), but the claim that generating
session keys from /dev/urandom is a complete no-no is rather
surprising.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com