Home page logo
/

nmap-dev logo Nmap Development 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-----
Hash: SHA1

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault