[16649] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: SSL/TLS passive sniffing

daemon@ATHENA.MIT.EDU (Werner Koch)
Thu Jan 6 19:46:24 2005

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: "Enzo Michelangeli" <em@em.no-ip.com>
Cc: <cryptography@metzdowd.com>
From: Werner Koch <wk@gnupg.org>
Date: Thu, 06 Jan 2005 10:43:32 +0100
In-Reply-To: <01c801c4f2c0$763146c0$0200a8c0@em.noip.com> (Enzo
 Michelangeli's message of "Wed, 5 Jan 2005 08:49:36 +0800")

On Wed, 5 Jan 2005 08:49:36 +0800, Enzo Michelangeli said:

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

> This "entropy depletion" issue keeps coming up every now and then, but I
> still don't understand how it is supposed to happen. If the PRNG uses a

It is a practical issue: Using /dev/urandom to avoid waiting for a
blocked /dev/random will let other processes wait infinitely on a
blocked /dev/random.

The Linux implementation of /dev/urandom is identical to /dev/random
but instead of blocking, (as /dev/random does on a low entropy
estimation) it continues to give output by falling back to a PRNG mode
of operation.

For services with a high demand of random it is probably better to
employ its own PRNG and reseed it from /dev/random from time to time.


Salam-Shalom,

   Werner




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