-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 1 May 2008 22:25:53 -0700 or thereabouts doug_at_hcsw.org wrote:
> On Fri, May 02, 2008 at 03:53:47AM +0000 or thereabouts, Brandon
> Enright wrote:
> > I did the same. I was not able to run -iR 5000 even with hours of
> > waiting. I love Linux but this really is the fault of the kernel
> > developers not recognizing the problem or accepting patches to
> > "fix" /dev/random. Yarrow, Fortuna, and other RNG schemes have been
> > coded up but haven't been integrated.
>
> No, IMO this is not a kernel problem. /dev/random (or /dev/srandom on
> oBSD) MUST block if it doesn't have enough entropy in the pool. For
> example, when you are creating a GPG key and it tells you to wave your
> mouse around or whatever, it is doing this to ensure that you will
> get a key that is not predictable, even if an attacker knows exactly
> when your system was booted, all PIDs of processes on your system,
> and even has a long sequence of random numbers generated by your
> system earlier.
I didn't mean to suggest that blocking isn't the right thing to do
when there is zero entropy left; it is. There is a place for pure
randomness in small quantities and there is a place for extremely high
quality randomness in large quantities.
Most people assume that /dev/random can be used for the latter. The
kernel devs assume (and by design, force) it to be used only for the
former.
Here is a bit about how Linux estimates entropy:
http://www.mail-archive.com/cryptography@c2.net/msg01708.html
It is my not very well researched opinion that not enough entropy
sources are tracked by Linux and that Linux greatly under-estimates the
entropy that can be derived from the sources it uses. I've never seen
an argument for why only 512 bytes are held onto at a time.
>
> All PRNGs have to be seeded. /dev/random ensures that your seeds
> really will be unpredictable and will never give you random data
> that hasn't been gathered from the "real world". If you can't take
> the blocking, well, that's what arandom/urandom are for.
Nod. It sure would be nice to have a /dev/entropy that behaved
like /dev/random and to re-implement /dev/random with a very high
quality PRNG like Fortuna.
This may have been the intention of random and urandom but the proper
usage of them is poorly understood by most.
>
> Remember netscape in 95? They seeded their PRNG with the PID, the
> PPID, and the time, all MD5ed, and it still wasn't good enough:
>
> http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html
100% agreed. If you liked the Slammer/Sapphire analysis (previous
email), you'll love the Witty analysis:
http://www.cc.gatech.edu/%7Eakumar/witty-draft.pdf
Last I spoke to Colleen Shannon she was still working on interesting
results with the Witty PRNG.
>
> Doug
Thanks for the ISSAC and DNET/ARC4 pointer. I'd feel better using one
of these than the LCG I suggested anyways. I'll probably end up
working with the DNET PRNG as it's already there and it's well tested.
We've stretched this thread pretty thin by now -- nobody said
nmap-dev couldn't have a bunch of random chatter :-)
Brandon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkgaq6AACgkQqaGPzAsl94JntgCgigfEz53mQsOVYd9G+MCEe9da
ONAAnRRKVEKWu0NGhMAFv1M6Kz/iVLWG
=SGbx
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on May 01 2008
Intro
