[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071211013414.GS17037@thunk.org>
Date: Mon, 10 Dec 2007 20:34:14 -0500
From: Theodore Tso <tytso@....edu>
To: Matt Mackall <mpm@...enic.com>
Cc: Marc Haber <mh+linux-kernel@...schlus.de>,
Eric Dumazet <dada1@...mosbay.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Adrian Bunk <bunk@...nel.org>, linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>
Subject: Re: Why does reading from /dev/urandom deplete entropy so much?
On Mon, Dec 10, 2007 at 05:35:25PM -0600, Matt Mackall wrote:
> > I must have missed this. Can you please explain again? For a layman it
> > looks like a paranoid application cannot read 500 Bytes from
> > /dev/random without blocking if some other application has previously
> > read 10 Kilobytes from /dev/urandom.
>
> /dev/urandom always leaves enough entropy in the input pool for
> /dev/random to reseed. Thus, as long as entropy is coming in, it is
> not possible for /dev/urandom readers to starve /dev/random readers.
> But /dev/random readers may still block temporarily and they should
> damn well expect to block if they read 500 bytes out of a 512 byte
> pool.
A paranoid application should only need to read ~500 bytes if it is
generating a long-term RSA private key, and in that case, it would do
well to use a non-blocking read, and if it can't get enough bytes, it
should prompt the user to move the mouse around or bang on the
keyboard. /dev/random is *not* magic where you can assume that you
will always get an unlimited amount of good randomness. Applications
who assume this are broken, and it has nothing to do with DOS attacks.
Note that even paranoid applicatons should not be using /dev/random
for session keys; again, /dev/random isn't magic, and entropy isn't
unlimited. Instead, such an application should pull 16 bytes or so,
and then use it to seed a cryptographic random number generator.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists