Integrated crypto

Robert Connolly cendres at
Tue Apr 6 10:23:39 PDT 2004

I'm not finding a better way around this ssp/entropy problem. Every function 
is using 4 bytes of random data per runtime. There's two types of entropy 
software. Some actualy gather entropy, like EGD and EAGD, and some rehash 
urandom, like frandom(kernel) and arandom(libc). The first type typicaly 
preform really poorly compared to the kernel. Userland entropy gathering uses 
too much resources for ssp. Frandom and arandom make no difference. They're 
good for filling discs, not for millions of 4 byte requests. Frandom uses 4 
bytes from urandom just to seed itself, so there is absolutely nothing gained 
from using it (unless  you want to fill huge files). Arandom from libc uses 
urandom... The bsd's have arandom in the kernel and it has its own pool, so 
unused bytes can be reused, but Linux does not have this. I've compared the 
code between Linux's and bsd's random.c, they're originaly based on the same 
code (same copyright owner and date), but now are too different for me to 

So... if we do nothing, and keep using urandom, we are depleting often all the 
entropy durring moderate operations (like running make); urandom will be 
hashing mainly against gettimeofday while random is empty, and ssp may be 
vulnerable to a sophisticated attack. I'm wondering if its safe to let a 
second rng (like-arandom) reseed itself against its own output. A part of its 
pool can be reserved, when the rest is empty the reserved part is rehashed 
and discarded, and repeat. It would only need to read from urandom once, but 
could be reseeded anytime again later. Also, I've talked to the frandom 
author and he suggested opening /dev/frandom and never closing it.. this way 
it would only use 4 urandom bytes initial, and wouldn't need a new seed for a 
long time. I guess that could be done with EGD, pointing it at frandom to get 
random bits, but I'm not confident in EGD's preformance if its being used 10 
times a second for indefinite time. And I'm also looking at 
pax_get_random_long from the pax patch. Pax uses its own entropy, so it 
doesn't affect the kernel's pool. Frandom is using get_random_bytes which 
might be very similiar. <- 8kb source

More information about the hlfs-dev mailing list