From nmap's man page, it appears the "-O" argument to nmap enables this
output (add -v also), but
sudo nmap -sS -O -v localhost
doesn't get enough results for me on 10.3.7 to do TCP seq. prediction
(not sure why ; I even turned off my firewall and ran all the sharing
services and still same. Perhaps I need to upgrade nmap.). So, another
way to get some data...
gzip is one layman's way to do it (w/ a touch of information theory).
Pure randomness is completely devoid of information. Compression works
on patterns in data. Therefore, true randomness can't be compressed.
So...
EJs-Computer:~ ej$ cat /dev/random > here
#or dd a certain count
^C
EJs-Computer:~ ej$ ls -l here
-rw-r--r-- 1 ej ej 266240 28 Jan 17:39 here
EJs-Computer:~ ej$ gzip here
EJs-Computer:~ ej$ gunzip -l here.gz
compressed uncompr. ratio uncompressed_name
266308 266240 0.0% here
even @ best compression it doesn't help:
EJs-Computer:~ ej$ gunzip here.gz
EJs-Computer:~ ej$ gzip -9 --best here
EJs-Computer:~ ej$ gunzip -l here.gz
compressed uncompr. ratio uncompressed_name
266308 266240 0.0% here
so, there was 0.0% gain (the file size actually increased from the
overhead of the compression), so the input data was pretty much 100%
random (nothing to compress)...
Didn't find a similar -l flag for bzip2 ; but basically you can just
compare the original and resulting file sizes. Less compression means
more randomness...
EJs-Computer:~ ej$ bzip2 here
EJs-Computer:~ ej$ ls -l here.bz2
-rw-r--r-- 1 ej ej 267830 28 Jan 17:39 here.bz2
Crypto experts can chime in on other ways for measuring/testing
randomness and that last bit.
Cheers,
-ej
On Jan 28, 2005, at 5:24 PM, Christopher D. Lewis wrote:
Do any of my users have an idea how to gauge the quality of random
numbers generated by the prng? There's an article addressing sppofing
attacks based on guessing TCP sequence numbers that suggests that
after MacOS X gained a /dev/random the sequence numbers became
effectively random, but indicates the randomness involves 31 bits of
randomness to the other BSD operating systems' 32 bits. See
<http://lcamtuf.coredump.cx/newtcp/>. While the 32nd bit may not make
a big difference here, I was curious about its impact on generating
crytpographic-quality random data and the potential limits of the
randomness in Darwin's /dev/random.
Any thoughts on how to measure the randomness, and the tests one might
use to gauge the impact on applications where the quality of the
randomness is of critical importance?
