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
Sure.
- 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?
Similar: http://prngd.sourceforge.net/
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
Yes.
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?
https://wiki.alpinelinux.org/wiki/Entropy_and_randomness
timer entropy d
should provide on-demand entropy based on variances in timings of sleep command.
vs
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 
1 Like
That has very narrow uses - just for openssl rng.
http://vladz.devzero.fr/guchaos.html Looks interesting if it can indeed safely use known random input from a webserver like random.org.
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?
https://launchpad.net/pollinate
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!
https://www.whonix.org/pipermail/whonix-devel/2020-January/thread.html
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:
https://www.whonix.org/pipermail/whonix-devel/2020-February/001506.html
1 Like
Indeed.
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
- Turbid: A High-Entropy Randomness Generator [archive]
- Turbid User's Guide [archive]
- Not in Debian. [archive]
clrngd - clock randomness gathering daemon
- Not in Debian.
- http://freshmeat.sourceforge.net/projects/clrngd [archive]
- sys-apps/clrngd – Gentoo Packages [archive]
- Quote https://www.vanheusden.com/Linux/ [archive]
-
clrngd.tar.gz - this patch adds code to clrngd so that it will fork itself into the background. This tar-ball also contains a Makefile (the original distribution did not).
-
clrngd is a daemon which adds entropy to the kernel entropy-driver-buffers which it creates by looking at the differences between several clocks in your workstation/server
-
- added clrngd.tar.gz to github GitHub - adrelanos/clrngd: Clock randomness gathering daemon. Based on truerand algorithm. Adds entropy to the kernel entropy-driver-buffers by looking at the differences between several clocks. source: https://www.vanheusden.com/Linux/ / https://www.vanheusden.com/Linux/clrngd.tar.gz [archive] for better publication and easier readability
- licensing issue? BSD license with advertising clause.
- written in C
- writing log output broken for Patrick (might be since that works different nowadays with systemd)
- daemonizes itself (which is also outdated nowadays with systemd)
Got answer here:
https://www.whonix.org/pipermail/whonix-devel/2020-February/001507.html
1 Like
Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND
ent
sudo apt install ent
ent file_name
rngtest
sudo apt install rng-tools5
cat file_name | rngtest
dieharder
sudo apt install dieharder
dieharder -a -f file_name
PractRand
timer_entropyd
- vanheusden.com [archive]
- Not in Debian. [archive]
- [Whonix-devel] Entropy Daemon Questions [archive]
- Quote https://www.kernel.org/doc/ols/2014/ols2014-harris.pdf [archive]
-
I have written a daemon program which I believe solves this problem. I wanted a name distinct from the existing“Timer entropy daemon” [2], developed by Folkert vanHeusden, so I named minemaxwell(8), after Maxwell’s demon, an imaginary creature discussed by the great physicist James Clerk Maxwell. Unlike its namesake, however, my program does not create exceptions to the laws of thermodynamics.
-
The timer entropy daemon uses floating point math in some of its calculations. It collects data in a substantial buffer, 2500 bytes, goes through a calculation to estimate the entropy, then pushes the whole load of buffered data into random(4). My program does none of those things.
-
- Quote Crypt::Random::TESHA2 - Random numbers using timer/schedule entropy - metacpan.org [archive]
-
Uses a related method (jitter in timing data between usleeps) as this module, but inefficient and only suitable for bulk feeding of an entropy pool. Even after von Neumann debiasing, the output has distinct patterns and at most 0.5 bits of entropy per output bit. HAVEGE is a superior overall solution. However, note a number of other links at the site for other sources as well as links to hardware RNGs.
-
- Quote rngutils/README.md at master · infinity0/rngutils · GitHub [archive]
-
(This was inspired by timer entropy daemon^TED, which generates entropy in an inefficient way, and whose output fails FIPS 140-2.)
-
- Quote COLLECTING ENTROPY FROM DIVERSE SOURCES - Oracle International Corporation [archive]
-
The timer entropy daemon uses timing jitters over sleeps to produce entropy, much like MAXWELL. This demon is even more lightweight than MAXWELL, and makes no attempt to spice things up by doing small calculations, rather it only uses a 100 s sleep wrapped by gettimeofday(2) sampling.
-
randomsound
- In Debian. [archive]
- randomsound is being discouraged nowadays by its author [archive].
- Moar Entropy Sources [archive]
- revive randomsound? [archive]
Combining Multiple Jitter Based Entropy Gathering Daemons
1 Like
1 Like
Unrelated, can you please ask Stephan why he didn’t select BLAKE-3 hash instead? It is much faster than SHA3
1 Like
Based on load jitterentropy_rng kernel module using the kernel command line / kernel built-in jitterentropy_rng? · Issue #9 · smuellerDD/jitterentropy-rngd · GitHub it seems like Stephan is pretty relaxed about questions. Please just open a new issue under Issues · smuellerDD/jitterentropy-rngd · GitHub. Seems better if not all questions are coming from me.