Integrated crypto

Robert Connolly cendres at
Wed Mar 31 19:26:34 PST 2004

On March 31, 2004 02:13 pm, Bennett Todd wrote:
> 2004-03-31T18:12:24 Robert Connolly:
> > It looks to me like the hash of /proc/`pid`/environ changes with every
> > runtime. Its not entropy but it might be fairly unpredictable.
> Huh? That's just the environment.

Yes, you're right.

This is just brainstorm, maybe I've had too much coffee.

Non-crypto quality runtime random number generator for libc.
For when you want a random value for single use.

Take the values from gettimeofday, getpid, and environ. Gettimeofday is 
predictable, but knowing the microsecond a function was executed on isn't so 
predictable. The pid is not very predictable; its unknown to remote users, 
but is known to local users (there is a grsec option to hide pid's, but I'll 
assume its not being used). The reason I like environ is because, at least on 
modern kernels, its read only by owner. The environ value would be somewhat 
key in preventing a local attack because it would be the only real secret 
(except for the gettimeofday value). Any one of these values should be enough 
to foil a remote attack. The three values can be added together and hashed to 
provide programs with a random value at runtime, to do whatever they want 
with (ssp can use it).

Granted, this isn't as good as urandom. But this would be a fairly simple/fast 
function that provides values that don't repeat, without draining entropy 
from the kernel. I assume the pid allocation uses some of the kernels 
randomness, but that's the default anyway, and that just helps make sure this 
libc function stays random... from one boot to the next it shouldn't repeat 
itself because it is using the kernel's random indirectly.

I know its a bit flakey and only works at runtimes, and in fixed quantities.

More information about the hlfs-dev mailing list