Hi,
An interesting video for this:
https://www.youtube.com/watch?v=gp_90-3R0pE
I think OpenBSD gets entropy from many sources - thisn't very much
documented as far as I could see - such as time between interrupts,
application memory allocation. In general a multi-threaded environment
run by a clock running interrupts provides a good entropy that way.
There surely is much more that feeds into the entropy.
You can have a look at getentropy() and arc4random().
Further it appears a simple usb device can't have that much entropy.
Further arc4random polls out chunks of random to the various
applications so as long as you're not running a constrained environment
there's probably no issue (as long as you have several application
threads running simultaneously).
Notice the random seed is regenerated at boot and shutdown so as long
you've run once a certain amount of time and rebooted the computer once,
it's got to a state where random generator shouldn't predictable since
it bootstraps the entropy for next startup at shut-down every time.
Side note, for a server the source of entropy is plenty, network data
are completely asynchronous so mixing them up with internal states
probably make a very job.
I'd like to be able to help reading from your device, I haven't done
that before sorry.
Jean-François
Le 10/07/2020 à 00:21, ken.hendrick...@l3harris.com a écrit :
I wrote:
How do I use a hardware random number generator to
continuously seed /dev/random with new truly random numbers?
--- Theo de Raadt wrote:
We consider these devices boring, because the kernel does a good enough job
creating random.
randomness only has a bootstrap problem. And these devices don't solve the
bootstrap problem.
I'm thinking of headless servers, where randomness can ONLY come
from the network. There is no keyboard, no mouse, etc.
I'm also thinking of first boot after install, when keys are generated.
I think that is what you mean by the bootstrap problem.
Thanks,
Ken
PS I'm also thinking of very old hardware, without RDRAND in the CPU.
Not to mention that you can't necessarily trust RDRAND!
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of
the intended recipient and may contain material that is proprietary,
confidential, privileged or otherwise legally protected or restricted under
applicable government laws. Any review, disclosure, distributing or other use
without expressed permission of the sender is strictly prohibited. If you are
not the intended recipient, please contact the sender and delete all copies
without reading, printing, or saving.
