OpenSSL (which I've now confirmed that I've finished studying) relies on sourcing truly random inputs an attacker cannot predict. Linux provides this via the /dev/random device-file!
The central add-rotate-xor hashing (+ fastpath) function here is a variation on CRC checks, apparently not cryptographically-secure but rapid enough to be called upon every CPU interrupt. May be wrapped in logging and/or mutexes.
There's a mutex-locked callback list, possibly called upon reseed.
That hashing function is wrapped in several more-public APIs so kernel-space (or even userspace) drivers can feed in more randomness from outside the computer itself. A lower-bound on the amount of randomness Linux has is estimated (mutex-protected), but that's barely relevant beyond bootup. The amount of "entropy" in the pool always increases, you can't make it less random except by looking at kernel memory!
The core /dev/random logic implements some of its own fallback entropy harvesters (from e.g. timers, better than nothing!), with most of the code going into the public APIs.
When returning entropy (mutex-protected & logged) out of this pool it SHA1 hashes a computed number of bits & (is this needed?) subtracts off a certain amount of estimated entropy. This hash is mixed back into the entropy pool to ensure it remains unknown.
Exposes /dev/[u]random dev files & a getrandom() syscall.
Add comment