/dev/random and linux security issues (kinda long)
    aluminumsulfate at earthlink.net 
    aluminumsulfate at earthlink.net
       
    Sun May 15 10:16:00 EDT 2005
    
    
  
   Date: Sun, 15 May 2005 02:55:59 -0400
   From: mike ledoux <mwl+gnhlug at alumni.unh.edu>
   When that simple test shows it is clearly true that /dev/random
   blocks just as stated in the man page.  The kernel's RNG may not be
   very good, but that is a separate issue.
Yes, it's true that the device *blocks*. It just does not block *long
enough* to gather the entropy it is supposed to.
   If you want /good/ random data (well, as good as the kernel is going
   to give you for free, anyway), you should not be using /dev/urandom.
Ah!  My mystical hand-waiving has been revealed!  %^]  You're right... I
mistakenly used /dev/urandom for that test....  But the same kind of
anomalies occur using /dev/random:
dave at bat$ dd if=/dev/random bs=1 count=64 | ./string2dec.pl | ./dec2base95.pl 
64+0 records in
64+0 records out
64 bytes transferred in 0.004915 seconds (13021 bytes/sec)
$27"L4nGf\MaWk/p9afkH R>uz9999p  %au\R/CaM4RuMp>zz ppza zCp4 /CkkuMapRR%H R/u!
dave at bat$ dd if=/dev/random bs=1 count=64 | ./string2dec.pl | ./dec2base95.pl 
64+0 records in
64+0 records out
64 bytes transferred in 0.005279 seconds (12123 bytes/sec)
[VS~dz]auCMHRRp%H4u44a9upRpuW44/>kkR >zR9R\aCuz>CzR**p\\z>W**au *C/%>WaC Cp>H8
   > I don't have the tools to do a formal frequency analysis of it...
   64 bytes is far too small a sample to draw any sort of conclusion
   from, and there is quite a bit more to this problem than simple
   frequency analysis anyway.
There is much more to this than frequency analysis, I agree.  But
frequency analysis should be sufficient to show that the data ISN'T
random.  Suppose, for example, that a string of 79 "6"s came out....
   > Interestingly, my available entropy seems to *increase* as /dev/random
   > is read, and then max out at 4096.
   > 
   > dave at bat$ cat /proc/sys/kernel/random/entropy_avail 
   > 4096
   That is bizzare, and definitely not the case on any of my systems.
   Are you reading that while you are reading from /dev/random, or
   after?  It is possible that in typing and executing the command to
   check entropy_avail you are generating enough entropy to fill it,
   but that seems unlikely.
cat /proc/sys/kernel/random/entropy_avail; dd if=/dev/random bs=1 count=64 | ./string2dec.pl | ./dec2base95.pl; cat /proc/sys/kernel/random/entropy_avail
No typing involved.  But the filters running in between might be
refilling the pool. (Page faults?)  Anyhow, my entropy_avail stays at
4096. (Current uptime: 91 days.)
I even checked the devices to make sure they have the correct numbers:
crw-rw-rw-  1 root root 1, 8 Dec 31  1969 /dev/random
cr--r--r--  1 root root 1, 9 Dec 31  1969 /dev/urandom
Anyhow, I've gotten a jar and put 128 pennies in it.  I'll be sure to
let you know if I find any patterns in the data from that, too. ;)
Dave
    
    
More information about the gnhlug-discuss
mailing list