mailing list archives
Re: [Bug]? -iR <num_hosts> on windows XP generates duplicate targets
From: Brandon Enright <bmenrigh () ucsd edu>
Date: Fri, 2 May 2008 05:50:16 +0000
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 1 May 2008 22:25:53 -0700 or thereabouts doug () hcsw org wrote:
On Fri, May 02, 2008 at 03:53:47AM +0000 or thereabouts, Brandon
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
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
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:
100% agreed. If you liked the Slammer/Sapphire analysis (previous
email), you'll love the Witty analysis:
Last I spoke to Colleen Shannon she was still working on interesting
results with the Witty PRNG.
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 :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org