Re: [PATCH] Add the ability to generate quality random IPs without any duplicates

[Brandon Enright <bmenrigh () ucsd edu>]

Sorry for the top-post.  Still working off of my phone.

Regarding period: I designed it for 2^32 period with no holes but  
you're right, I should test it.  There is a slight chance the period  
is 2^32-1 or worse, 2^(32-1).

I got to thinking about the tweak I designed and I think it provides  
about 6 dimensions of independance.  If I can find something that lets  
me plot 3d points each with unique RGB color a pattern would form.  If  
so maybe I'll add s-boxes in between the two rounds.

I'll test the period and then run it through Diehard tests.

Brandon

Sent from my phone.  If you would like a digital signature for this  
email let me know and I will sign it later.


On Aug 24, 2009, at 5:48, Fyodor <fyodor () insecure org> wrote:

> On Sat, Aug 22, 2009 at 01:31:23AM +0000, Brandon Enright wrote:
> > Hey all, it's Friday and this week has burnt me out on "work  
> > things" so
> > I decided to tackle something fun.
>
> Neat!
>
> > Q: Why not just replace -iR with this new -iU option instead of  
> > having
> > both?
> >
> > A: Sometimes I want *really* high quality IPs.  Sometimes I don't  
> > want
> > to be bothered with duplicates. This patch is small, I think there  
> > is a
> > place for both.
>
> I think supporting both for your initial patch is a great idea, as it
> makes it easy to test the different strategies and compare.  But Nmap
> itself only needs one random IP generation mechanism (whatever one we
> think is best).  If someone wants a different approach, nothing stops
> them from generating random IPs however they like and feeding them to
> Nmap with -iL.
>
> So the next question is: which mechanism is best?  Avoidance of
> duplicates is a useful property.  I often pass my IP lists to sort and
> uniq for this very reason.  The number of duplicates aren't material
> unless you are scanning a huge number of IPs (your example of 10
> million IPs shows about 0.15% duplicates).  But they are still
> annoying.
>
> So I'm in favor of a no duplicate approach for Nmap *if* there aren't
> any significant downsides.  Does anyone see any problems in using this
> approach?  The code is small and doesn't appear computationally
> intensive.  I haven't evaluated the quality of randomness, though
> Brandon's graphs look promising.  Perfect randomness isn't critical
> here anyway.  Brandon: have you tried generating billions of these to
> verify that the period is as large as you expect and that the full
> group doesn't have holes in it (besides the expected ones from
> ip_is_reserved())?
>
> Cheers,
> -F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org