@Patrick where does the recommendation of installing jitterentropy on the host go?
Edit by Patrick:
HulaHoop via Whonix Forum:
@Patrick where does the recommendation of installing jitterentropy on the host go?
Not sure.
and also
Perhaps @torjunkie will move it to a more suitable place.
Host operating system specific. Documentation for Debian (based) would
be enough for now. Mac and Windows can be left TODO as exercise for
reader / welcome contributions.
Also mention haveged, and Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND?
Haveged is only good for VMs AFAICT also it can’t influence early boot seeding entropy which is the main problem of the RNG.
haveged and jitterentropyare both just daemons in Debian. Not kernel modules (which could act earlier).
Check:
apt-file list jitterentropy-rngd
apt-file list haveged
systemd unit files look similar.
/lib/systemd/system/jitterentropy.service
DefaultDependencies=no
After=local-fs.target
Before=sysinit.target
/lib/systemd/system/haveged.service
DefaultDependencies=no
ConditionVirtualization=!container
After=apparmor.service systemd-random-seed.service systemd-tmpfiles-setup.service
Before=sysinit.target shutdown.target
Actually, opposite argument has been made.
i.e. haveged may not work great inside VMs. It was developed for hardware.
Actual testing revealed it is ok as per haveged tests ( Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND ) and dieharder.
And independently from above, under the current theory of kernel entropy mixing it’s always good to throw something else into the mix?
jitter is only effective if the accompanying kernel module is included - which it is in the Buster kernel:
CONFIG_CRYPTO_JITTERENTROPY=m
Now whether it does load the module at boot or not is another question that we need to confirm.
It would not work in VMs where the tsc CPU instruction is blacklisted like I used to do before I just passed through all instructions for spectre mitigations to have effect in the guest.
Correct me if I’m wrong, but don’t both use the exact same source for entropy generation? In that case havege would be redundant and not nearly as useful as jitter because it can;t do early boot stuff.
HulaHoop via Whonix Forum:
Correct me if I’m wrong, but don’t both use the exact same source for entropy generation? In that case havege would be redundant and not nearly as useful as jitter because it can;t do early boot stuff.
Premise: extra providers can only improve entropy, even feeding totally
predictable data to /dev/random cannot worsen its quality
Both haveged and jitterentropy use same source of entropy: maybe?
Both haveged and jitterentropy use same algorithm: no (haveged uses
haveged algorithm, jitterentropy does not say so)
Both haveged and jitterentropy use same implementation: no
Conclusion: worthwhile to have both
Let me know if my logic has a mistake.
Yes both use the CPU timers.
Different projects different algos, but I think entropy randomness is determined by the source rather than the gatherer’s interpretation. Either way it won’t harm and you might as well add it to the wiki.
Going back to the topic of /dev/random vs /dev/urandom the jitterentropy userspace daemon prevents blocking of /dev/random and makes sure urandom is sufficiently seeded early enough to resolve the risk of weak seeds.
I can easily write an interpreter for any kind of input data which will have completely predictable output. (For any input I get I output a 0. That would be to demonstrate how - only in this case obvious - coding bug can mess things up.)
These algorithms I think there’s a lot room to mess up in sublet ways which stay undetected in public for decades or forever.
Alright.
kernel modules not active in Qubes Debian buster. jitterentropy systemd unit file not complaining.
Lowered some claims:
System Hardening Checklist: Difference between revisions - Whonix
Quote Debian -- Details of package jitterentropy-rngd in buster
The seeding of /dev/random also ensures that /dev/urandom benefits from entropy. Especially during boot time, when the entropy of Linux is low, the Jitter RNGd provides a source of sufficient entropy.
The first sentence doesn’t necessarily mean that happens during early boot. (Seeding of /dev/urandom.)
The second sentence may be true but not connected to seeding /dev/urandom early enough.
Quote System Hardening Checklist: Difference between revisions - Whonix
makes sure /dev/urandom is sufficiently seeded early enough in the boot process to resolve the risk of weak seeds
I have to be nitpicky here about “provides a source of sufficient entropy” vs “makes sure /dev/urandom is sufficiently seeded early enough”
Also if I look at:
/lib/systemd/system/systemd-random-seed.service/lib/systemd/system/urandom.serviceI am not sure /lib/systemd/system/jitterentropy.service runs before these.
/lib/systemd/system/jitterentropy.service may provide entropy but I don’t think it changes anything about any seeds of /dev/urandom. That would be up to systemd but there I don’t see this interaction.
Also, I don’t understand, if jitterentropy is a kernel module (not part of jitterentropy-rngd!), why it also a daemon?
Needs asking the jitter dev because I saw something about this module not having an API one can directly query for random numbers. So it may be working just at a level we can;t detect.
Fair enough. We need to be 100% sure so I will ask.
Got this from a technical writeup not something I made up 
For best accuracy I’d opt for the second sentence.
https://pthree.org/2016/05/24/cpu-jitter-entropy-for-the-linux-kernel/
As mentioned in the list, unfortunately, loading the kernel doesn’t automatically top-off the entropy estimate of the internal state of the CSPRNG (/proc/sys/kernel/random/entropy_avail). As such, /dev/random will still block when the estimate is low or exhausted. So you’ll still need to run a userspace daemon to prevent this behavior. The author has also shipped a clean, light userspace daemon that just reads the data provided by the jitterentropy_rng.ko kernel module, and uses ioctl(2) to increase the estimate. The jitterentropy_rng.ko module provides about 10 KBps of random data.
Again, this isn’t anything that something like haveged(8) doesn’t already have access to. However, by taking advantage of a loaded kernel module, we can ensure that randomness is being collected before the CSPRNG is initialized. So, when CSPRNG initialization happens, we can ensure that it is properly seeded on first boot, minimizing the likelihood that exact keys will be created on distinct systems. This is something haveged(8) can’t provide, as it runs entirely in userspace.
Only after I force load the module: jitterentropy_rng.ko does it appear under /proc/crypto
root@host:/home/user# modprobe -f jitterentropy_rng
root@host:/home/user# cat /proc/crypto | grep jitter
name : jitterentropy_rng
driver : jitterentropy_rng
module : jitterentropy_rng
Let’s decide whether we will include a modules.d snippet to do this on boot or if it makes sense to report upstream in Debian:
Great work! In my Qubes buster VM I can see it now using cat /proc/crypto | grep jitter command.
cat /proc/crypto | grep jitter
name : jitterentropy_rng
driver : jitterentropy_rng
That might be since Qubes buster VMs are actually using dom0 provided kernel (which comes from Fedora?).
Yes. Most definitely.
I suggested to Debian maintainers to switch kernel config to ‘y’ instead of ‘m’ like Fedora does to solve this.
Meanwhile I tested a workaround on boot that has the effect we need:
/etc/modules-load.d/jitterentropy_rng.conf
contains:
jitterentropy_rng
cat now returns module name as expected.
The latest reply from Stephan corrects a lot of misconceptions.
Summary:
The kernel module does not matter for urandom seeding. This is handled exclusively by the systemd service which already works for us.
What’s the purpose of the kernel module? Still useful for us? If useful,
why Debian doesn’t enable it by default? Can we convince them? If it’s
not useful, then I am puzzled what the purpose of that kernel module is?
To seed the kernel DRBG which is different from the /dev/?random interfaces.
If it doesn’t affect urandom then no.
Since I don’t really know what it is useful for I can’t argue for it properly.
Not really. Even when I thought it had consequences for random, they suggested I just add a module load snippet in .d
Me too I guess the question is what the kernel DRBG is good for. Can you please join the convo on our ML and ask because I don’t want to exhaust Stephan’s patience educating a non-cryptographer pleb like me.
UPDATE:
Stephan says Kernel DRBG is important for ECC crypto as well as other stuff and therefore it makes sense to have upstream enable the module by default.