Integrated crypto

Adrian Fisher mobiletiw at
Tue Apr 6 11:38:20 PDT 2004

Why not use CPU speed clocks?  I know they are known but they very 
rarely match the quoted speed (this system is a P4 2.8 GHz system and 
runs at different speeds regularly (sometimes faster, sometimes slower) 
depending on the temperature of the room, what it is doing, etc.  
Another option is to make use of the speed of cache and memory, while 
these figures can be gained by the system they can be incorporated into 
an algorythym that masks them.

Just an idea.


Robert Connolly wrote:

>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