Information
ID: 817
PHID: PHID-TASK-3la4ualaafxtn5dyhvei
Author: HulaHoop
Status at Migration Time: resolved
Priority at Migration Time: Normal
Description
Summary: jitterentropy is a RNG designed in the spirit of haveged (using CPU timer jitter as entropy source) except it made up of a kernel module - mainlined since Linux 4.2 and a userspace daemon (jitterentropy-rngd*) to prevent /dev/random from blocking. The advantage of jitterentropy is by taking advantage of a loaded kernel module, it can ensure 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 can’t provide, as it runs entirely in userspace.
*jitterentropy-rngd is now included in Debian sid so we should look out for its eventual inclusion in stable next.
http://www.chronox.de/jent.html
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
https://pthree.org/2016/05/24/cpu-jitter-entropy-for-the-linux-kernel/
It would be a good alternative to haveged especially for hypervisors that don’t support virtio-RNG and so don’t have access to entropy sources early during boot process.
- mailing list thread answered with jitterentropy developer: How to confirm jitter .ko was loaded (and more explanations provided)
- #927972 - set jitterentropy_rng.ko to built-in - Debian Bug report logs
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927974
- jitterentropy-rngd - #11 by HulaHoop
- ask upstream developers about Efficacy of jitterentropy RNG in Xen · Issue #4174 · QubesOS/qubes-issues · GitHub
Comments
Patrick
2019-04-14 16:56:11 UTC
Patrick
2019-04-14 17:00:26 UTC
Patrick
2019-04-15 10:52:14 UTC
Patrick
2019-04-17 15:24:12 UTC
HulaHoop
2019-05-01 00:21:43 UTC
Patrick
2019-05-01 00:23:51 UTC
HulaHoop
2019-05-22 05:34:26 UTC