[Cryptography] Generate Random Data From Sound Card
Jon Callas
jon at callas.org
Sat Mar 7 19:18:55 EST 2026
> On Mar 7, 2026, at 12:32, Kent Borg <kentborg at borg.org> wrote:
>
> I think the difference between /dev/urandom and /dev/random has mostly gone away, I said /dev/urandom because /dev/urandom was the one that has always worked: read it and you get output, whereas /dev/random would throttle on mostly spurious entropy estimations. (The guy turning off all the entropy sources was trying to make /dev/random more honest, a reasonable goal, executed stupidly.)
>
> But these days I don't know that there is much difference.
Oh, it's all more confusing than that. Some time ago, Linux stalled /dev/random, but not /dev/urandom. FreeBSD stalled /dev/random until there was enough goop in the pool, but never again. Darwin never stalled. I don't know what other BSDs did. Windows is just complex -- it uses Fortuna tweaked in ways I never paid attention to.
Stalling went out of favor at some point, particularly because more and more OS kernel things started using it for all sorts of things. ASLR, port assignment, memory layout, all sorts of things that can't stall. The small amount of fact checking I did said that Linux /dev/random is now "virtually" the same as urandom nowadays.
I have a other comments, but they're close to being a distraction.
I like what you also said:
> What you feed in does not have to be "random" at all. It just has to be unknown to whomever might want to predict your RNG's output. If your attackers don't know what you considered feeding in, and whether you actually did, and when you fed it in in relation to other entropy inputs…it will improve your RNG's output. (Unless the RNG is swamped with so much input that it decides to ignore some.)
Yes! This! It does not hurt at all, and as a matter of fact, with any RNG construction that is digesting up inputs with a hash function, sponge, etc. there's no harm and small upsides for throwing whatever into the pool.
>
> [...] the Kent who has currency in his wallet with serial numbers of it, and though those serial numbers are in no way "truly random", it is exceedingly likely no one in the world knows what those serial numbers are, which makes them potentially useful to a good RNG, and certainly no harm.
Oh, yes. This is one of the points I was trying to make. All we need is something that is arbitrarily hard for an adversary to guess, even if it's a set of constants all jammed together.
If we assume a totally predictable, Classical Newtonian universe, then lots of real world observations that are "knowable" in an abstract sense are still just fine. Photons going through a lens that has manufacturing differences, falling on a sensor with its own manufacturing differences works great. An audio sample of ambient hiss also works. Hiss is lower bandwidth but more controlled.
Any sort of image processing system is highly unpredictable. We've focused on the photo subject -- lava lamps, dead leaves, you name it -- and also includes aperture (depth of field changes what's falling on the sensor), shutter speed (motion blur or not), jitter in the camera mount whether it's a person or fixed, dust on the lens or in the air, and so on. An adversary could know everything, but they don't. There's too much to know, and if we're just going to hash the output of the sensor it's pretty intractable to compute.
Jon
More information about the cryptography
mailing list