urandom entropy

Robert Connolly robert at linuxfromscratch.org
Wed Feb 9 13:29:46 PST 2005


I've managed to make a sysctl interface for urandom, using 
get_random_bytes(3). get_random_bytes(3) is supposed to be non-blocking, like 
urandom, but unlike urandom it drains kernel entropy in a hurry 
(/dev/urandom's old behaviour).

I did some benchmarking with an arc4random library. It's very fast, I couldn't 
measure any performance loss when I used it for propolice. OpenSSL, OpenNTPD, 
and other BSD based software look for arc4random(3) during configure. This 
library is a 9.5KB patch, maybe 4KB of source without comments, so I'm 
guessing it would increase the size of libc (stdlib) by like 1KB, or maybe 
less :-)

So, I'm thinking to make two separate libraries, one for erandom and one for 
urandom. The one for erandom will be for propolice, mktemp(1), libc's 
mktemp(3), and anything else non-crypto. Another twin library for urandom, 
aliased arc4random, for OpenSSL and anything crypto. Both the libraries will 
be arc4random just with the source interfaces changed. Erandom and urandom 
both use md5 hashes, arc4random uses arcfour (rc4 clone) stream cipher, the 
combination should be pretty robust (the don't share the same 
vulnerabilities).

The advantage of the library is that if sysctl fails for any reason it can 
keep going, try /dev, and so on, ending with gettimeofday or getpid. The 
urandom library can also try sysctl random.uuid which already exists in the 
vanilla kernel, however it is blocked to normal users in grsecurity kernel's.

The sysctl urandom patch would need to be added to the frandom patch, which 
means renaming frandom's patch to something else. The frandom maintainer 
doesn't want to support extra stuff for urandom.

For library function names I think name the urandom library arc4random() and 
name the erandom library arc4random2() (or maybe arc4randomII).

I've already done half the work on uClibc. Next I need to modify mk*temp(3) to 
use arc4random2 instead of /dev/urandom.

This is why I've been so quiet lately btw.

robert



More information about the hlfs-dev mailing list