SSL/TLS passive sniffing

[Andy Isaacson]

On Wed, Dec 22, 2004 at 07:43:13PM +0100, Florian Weimer wrote:
> * 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.

That's basically what /dev/urandom does, no?  (Except that it has the
undesirable side-effect of depleting the entropy estimate maintained
inside the kernel.)

> > 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.)

On my PIII/666 running 2.4.26, I get 1.4 MB/sec from /dev/urandom.
Seems plenty fast enough to me.  (Fast, of course, being orthogonal to
secure.)

> 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.

I'm baffled by the post you reference:

Andrew Suffield writes on Mon, 20 Dec 2004 06:11:08 -
> The security of the session is limited by the randomness of the
> weakest key used. If you're going to use /dev/urandom then you might
> as well just not encrypt the session at all. It wouldn't be massively
> less secure, and it would be quite a lot faster.

I *think* what that says is "generating a session key based on entropy
from /dev/urandom is security-equivalent to no encryption at all".
Which is so obviously false that I can't imagine that I'm not
misreading.  I will grant that *if* an attacker can reconstruct the
state of the entropy pool (which in theory is possible if the attacker
can gather N bits of information about the outputs, but would require a
significant advance over the state of the art in cryptanalysis of the
hash function, and probably about 2^N work) then a key generated from it
is insecure.  But the difficulty of extracting that much information
about the entropy pool is enormous, and the challenge of reconstructing
the state, given that information, is ... large.

It would be less work to build a SQUID [1] and snoop the operation of
your ALU from the white van parked across the street from the data
center.

So, I agree with you - while it would be preferable to generate session
keys using the most conservative entropy estimates, it's a perfectly
reasonable engineering compromise to use /dev/urandom.  I'd rather have
Good Enough encryption, universally deployed, than fall for the Purity of
Essence^H^H^H^H^H^H^HRandomness whackos' claims that "Everyone must plug
a Geiger counter into their serial port or We're All Going To Die".

BTW, the Linux kernel guys are actively working on improving the
security of /dev/*random and could benefit from experienced
cryptographers willing to review work and make suggestions.  Check out
the linux-kernel archives for the past few months for subjects
mentioning /dev/urandom and /dev/random.

[1] Superconducting QUantum Interference Device, the Gibsonian gizmo
    used by the dolphin in _Johnny Mnemonic_ to extract "80 *Gigabytes*!"
    of information from the courier's brain-mounted memory module.

-andy

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