/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