[Cryptography] Generate Random Data From Sound Card

[Kent Borg]

On 3/6/26 8:16 AM, Patrick Chkoreff wrote:
> In other words, I would just rely entirely on Theodore Tso's code.  Go 
> Ted.

I like Ted's code, but if you want to Xor in additional (uncorrelated!) 
data, go ahead. It can't hurt. Linux /dev/urandom is great but the idea 
that RNG is solved, so simplify, and don't look for additional entropy 
always worries me.

Ted's code is quite happy to have you feed in additional entropy 
sources. Write new data into /dev/urandom.

I once architected a "casino grade" RNG that I think I got approved in a 
couple jurisdictions (there were only three at that point: NV, NY, and 
Indian casinos). It was just a packaging of a fairly early version of 
Ted's Linux code, Though those were dark days when someone else was 
maintaining the driver and he was on an idiot mission, busily removing 
every entropy source he could because if the source couldn't be 
quantified it had to go, starving the kernel of entropy. A misguided 
idea, one that might be characterized as removing "squish", I think 
could be the word. I followed him around (in our copy of the kernel) 
turning back /on/ every source I could find. I also searched our 
hardware looking for every other source of both entropy and uniqueness I 
could find (unique machine readable serial numbers and old fashioned 
hard-coded MAC addresses, etc). This was a long time ago, at that point 
the power-on value of DRAM didn't come up zeros but had crap in it that 
wasn't quite the same every time. We had 1GB of RAM, I wrote that into 
/dev/urandom at every boot. There was a fan from which I could read 
speed, there was a voltage or two I could read, I think I tracked down a 
temperature or two. I also devised a manufacturing procedure that 
uniquely initialized each unit's stored entropy pool on disk. I also set 
up a cron job to regularly store the pool so on a machine that wasn't 
designed to be politely powered down the stored value read at boot would 
be different at every boot.

My approach was to trust a quality RNG, but feed it well.

These days I would take a similar approach, but I would be well 
reassured that at current system clock rates, time stamping when 
interrupts get serviced is a great source of entropy, no matter the 
interrupt source. Maybe not a good source of "theoretical" entropy but 
still nice squishy entropy in the sense that anyone at any physical 
distance beyond inches (if that) cannot know what those multi-GHz 
timestamps are going to be. And every interrupt or two has to include a 
bit or two of entropy. And if there are a lot of interrupts happening, 
that's real. Hash or encrypt it and that's a quality RNG.


-kb, the Kent who asserts that as security holes go, RNGs usually work 
well provided (1) they aren't crap in the first place and (2) they are 
actually hooked up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260306/7ce27290/attachment.htm>