[Cryptography] Generate Random Data From Sound Card

Byrl Raze Buckbriar sub0 at octade.net
Sat Mar 7 06:42:22 EST 2026


On Fri, 6 Mar 2026 21:11:53 +0100
David Kane-Parry via cryptography <cryptography at metzdowd.com> wrote:

> On 4 Mar 2026, at 23:37, Jon Callas <jon at callas.org> wrote:
> > On Mar 3, 2026, at 15:54, Byrl Raze Buckbriar via cryptography <cryptography at metzdowd.com> wrote:  
> >> Try one command to convert the sound card into a TRNG.
> >> 
> >> It should work with the audio muted.  
> > 
> > That's really cool! Same principle as the camera with a lens cap on. Ambient hiss is another source for free. Thanks for pointing that out, it's another arrow in the quiver of combating  the Quantum Credulity Effect, that the very word "quantum" sucks people's brains out and leaves them incapable of thought.  
> 
> There's also, for example, the thermal noise that Intel uses as a part of RDRAND.
> 
> - d.

Don't forget RDSEED. I cut out the AES middleman for a few kilobits of my keygens.

Linux has /dev/hwrng for direct access to the hardware random generator on modern chipsets. I can't say how trustworthy it is or which ASM commands it employs. But it's there so why not use it?

I use some hacks with RDSEED, RDRAND, RDTSC, /dev/hwrng, /dev/urandom, and a few other methods to generate a fresh random pool every time I want to replace the GnuPG random_seed file. When I generate a new keypair or encrypt a file I replace this file just to be safe.

I'm kind of miffed that OpenSSL and OpenSSH don't seem to have obvious and easy shell-based ways to seed their entropy during key generation. I don't feel like writing C programs and linking libraries for something that ought to be simpler and less time-consuming.

I remember two decades ago when generating truly random data was really hard and frought with unseen footguns. It seems a lot easier now with a few pet peeves.

-- 
= OCTADE = alt.rhubarb = misc.misc = sci.crypt =
= https://soc.octade.net/octade =


More information about the cryptography mailing list