Re: [Bug]? -iR <num_hosts> on windows XP generates duplicate targets

[Brandon Enright <bmenrigh () ucsd edu>]

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