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
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
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.
More information about the hlfs-dev