Moar Entropy Sources

Found a package called randomsound that uses audio cards as entropy source. Maybe I should re-add sound to the gateway in that case? Question is if it works with speakers muted and also if we need to be playing something for it to generate entropy.

I need to contact the upstream dev to know more

Daniel Silverstone

Email: <>

IRC: Kinnison, OFTC, #debian-uk

One of vanheusden’s daemons are already packaged for Fedora. Perhaps we can attempt converting them to .deb with Alien.

Both video-entropyd and audio-entropyd need access to sound and visual output so perhaps they would make sense more outside the VM while TimerEntropyd goes inside.

audio-entropyd (make sure your microphone isn’t muted), and video_entropyd (needs a camera or video input, might be able to hook up an analog antenna to a TV Tuner and set it to a static channel. It might also suck up some CPU cycles, so be careful)

libprngwrap uses LD_PRELOAD magic to force the few dumb programsleft that insist on using /dev/random to be redirected to urandom instead. Not sure if useful anymore when jitterentropy handles /dev/random and stops its blocking.


Asked by @HulaHoop:
Whonix-devel - randomsound questions

randomsound developer replied to the mailing list:

(But somehow the reply does not (yet) show up on the mailing list archive.)

From: Daniel Silverstone
On Sat, Nov 23, 2019 at 20:29:48 +0000, wrote:

Hi Dan. I’m a privacy distro dev and we are thinking of including
randomsound as an entropy source by default.

I’d recommend against that, reasoning below…


  • Does it gather entropy at all times when a soundcard is connected or only when there is sound playing?

It was designed to gather sound at all times it was running.

  • I assume form the package description it relies on sound output and not microphone input unlike van Heusden’s audio-entropyd

It was meant to use an input line, microphone or line-in.

  • How well can it function in a virtual environment?

Probably not usefully at all.

Randomsound was written a long time ago when computer hardware was simpler and less careful in terms of sound design. It was common for sound cards to be fairly (a) electrically noisy and (b) configurable. As such, I had a server which had need of entropy and a sound device which had no microphone or line-in device attached, and a sound card which could decouple its level monitoring from any controls (leave it floating) – this combination gave me a source of electrical and thermal noise I could harvest.

These days sound cards have mandatory filtering and are sufficiently complex that I would not like to make any assertions about an ability to set one up in the manner I recommended for use with randomsound. Virtual devices are even more controlled and thus even less likely to provide access to the kinds of entropy randomsound attempted to harvest.

These days I’d recommend ensuring that host systems harvest entropy from as many sources as possible, optionally sharing them around among themselves (I believe there’s software for this kind of thing) and then qemu has a virtio-rng device which allows transfer of entropy from host to guest (at a controlled rate).

There are also devices one can purchase which can increase the available entropy pool if your hosts are regularly running dry. For example the chaoskey by Keith Packard and Bdale Garbee.

Good luck with your quest for entropy, and thank you all for taking privacy so seriously.


Daniel Silverstone
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

No reports of anything is blocking now (before jitterentropy kernel module gets load) or later. Without any reports of anything blocking, I don’t think blocking would be an issue even if blocking somewhere. Blocking as far as I understand just means slower. Not catastrophic. sounds not so simple.

In sort libprngwrap enhances the PRNGs from libc. libprngwrap replaces the [s]rand, [s]random and [*]rand48 library calls with functions that get random values from /dev/urandom. This is supposed to be more secure.

Does not sound like a /dev/random vs /dev/urandom thing.

Then he links to where he contradicts that.

When your Linux system uses a lot of entropy-data from the /dev/random or /dev/urandom device, it might get empty and stall your application (in case of /dev/random) or return less secure data (in case of /dev/urandom).

There we have it again, “less secure data (in case of /dev/urandom”.

Awesome initiative and questions. Please keep digging / asking.

Can you make head or tail of Monitoring the kernel entropy buffer with mrtg? Try in KVM?

mrtg is in Debian:

1 Like

Installed it and output looks good.

Not seeing the benefit of this package over running plain cat /proc/sys/kernel/random/entropy_avail. It provides an easy to read cli interface to see server stats like uptime however.

1 Like

Good idea. Done.

True. However that is a separate issue. The sake of discussion “/dev/random vs. /dev/urandom” it can be simplified:
in case of Kicksecure / Whonix: just use /dev/random

Could be posted here Moar Entropy Sources

And this list could also use an update: Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND

Such as:

  • which tools have we exhausted
    • either installed by default or
    • discouraged by their original authors
    • discouraged for other reasons
  • which tools further research is required?
  • which tools in which priority (simplicity such as already in Debian or small code; impact) could be worked on next?
1 Like


  • Priority: generating better seeds on boot > injecting entropy from different input type > adding entropy in the same way as a currently installed tool
1 Like

By priority I mean, which software tool is worth packaging, installation by default? Which Software Package?

For example randomsound is not worth it as randomsound is being discouraged nowadays by its author [archive]. Therefore I guess we can scratch audio-entropyd too? On the other hand we could just try either randomsound and/or audio-entropyd. Randomness can never get worse. We could test if there is zero noise nowadays or if it’s still worth something.

Is timer_entropyd same as haveged or jitterentropy-rng? Or is it different?


  • Do reasons that made randomsound author discourage use of randomsound nowadays [archive] also similarly apply to video-entropyd?
  • VideoEntropyd is like timer-entropyd for a ‘video-4-linux’-compatible device. E.g. a tv-card or a webcam.

  • In our security guide we recommend to disable webcams in BIOS, to cover them or even physically remove them. Therefore worth bothering with it? If a webcam was blocked with a sticker would there be any noise that would generate randomness? The author will probably say we should check for ourselves. Any contributors coming to mind up to test that? Worth it? (Would be done on the host. Not inside VM. Any entropy enhancement of the host also makes VMs benefit.)

EGD - The Entropy Gathering Daemon looks quite old already. Worth contacting its author asking if it could still be useful nowadays? Useful to redirect its output of entropy to /dev/random?


Any other entropy generators?

Once there is any generator that generates randomness, I can do the polish. That is packaging, running it at early boot as daemon and redirecting the output of the randomness generator to /dev/random.

1 Like


Needs more info to determine

I’ll ask but audio_entropyd seems to be a different implementation which doesn’t blindly copy data until it meets sufficient entropy measures

The audio-data is not copied as is but first ‘de-biased’ and analysed to determine how much bits of entropy is in it.

Not clearly known. I’ll need to ask the author to confirm. The wiki description seems to describe differing implementations of a similar concept. I guess each unique algorithm will have its own take of the same source and add more noise?

timer entropy d

should provide on-demand entropy based on variances in timings of sleep command.


Haveged generates entropy based on CPU flutter. The entropy is buffered and fed into the entropy pool when write_wakeup_threshold is reached.

Good question for its author, but I will guess no? It depends on ever changing visual input rather than artifacts in accuracy of the recording device.

Yes. See if it does anything more than what the kernel RNG does and whether it is still useful even if it does.

Great :slight_smile:

1 Like

That has very narrow uses - just for openssl rng. Looks interesting if it can indeed safely use known random input from a webserver like

1 Like

Then let’s change the recommendation. A lot of damage can be done if attacker roots the host. They can spy using the speakers and even HDD platters and so removing access to devices in the TCB is of marginal benefit.

I don’t mind testing , but we must have some entropy measure to gauge the effectiveness.

1 Like

Maybe pollinate is similar?

I am skeptical about the approach of fetching entropy from remote sources.

What’s the intended benefit of the users and what use do others interpret into it? The intended benefit the by author might be “make my cloud image work” and then the security interested users might think “it’s to improve the security/entropy of my system”. Therefore we’d have to research that and perhaps ask the author if intended/tested use cases and limitations aren’t spelled out yet.

To use https securely (to connect to an entropy source) you need entropy to begin with (SSL session key). Well, I guess against adversaries who don’t try to MITM this might even improve entropy.

Is it worth the added attack surface, risk of exploitation by a compromised entropy source server?

Kernel is supposed to never worsen entropy no matter if a third party predicable source is added to and mixed with other legit entropy sources. However, how much do we want to trust this, add a potentially compromised third party remote source into the mix?

1 Like

Thanks for the many recent outreach activities!

HulaHoop via Whonix Forum:

That has very narrow uses - just for openssl rng.

It does not say that.

“offers an EGD compatible interface to obtain random data and is
intented to be used as an entropy source to feed other software,”

… “especially software based on OpenSSL.”

especially isn’t exclusively. Maybe misread.

“entropy source to feed other software” our “other software” here would
be /dev/random.

Asked about it just now:

1 Like


Me too. It’s just a mere curiosity. His package description made me wonder if it is possible to use a unsafe source of randomness and make it safe. I don’t think the added remote attack surface is worth it either, but something to learn about how entropy works.

If that is the case then theoretically the code could be implemented to support untrusted local hwrngs and mitigate all risks while adding value.

1 Like

turbid - High-Entropy Symbol Generator

clrngd - clock randomness gathering daemon

Got answer here:


1 Like

A post was merged into an existing topic: early-rng-init-tools for better entropy?

Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND


sudo apt install ent

ent file_name


sudo apt install rng-tools5

cat file_name | rngtest


sudo apt install dieharder

dieharder -a -f file_name

PractRand [archive]



Combining Multiple Jitter Based Entropy Gathering Daemons

1 Like

1 Like
1 Like