[Whonix-devel] How to confirm jitter .ko was loaded
smueller at chronox.de
Fri Apr 26 16:09:03 CEST 2019
Am Mittwoch, 24. April 2019, 20:36:01 CEST schrieb procmem at riseup.net:
> On 4/24/19 6:21 PM, Stephan Mueller wrote:
> > Am Mittwoch, 24. April 2019, 19:30:28 CEST schrieb procmem at riseup.net:
> > Hi,
> >> Hi Stephan. Whonix dev here. We are a VM based privacy distro and so are
> >> very interested in jitter for our RNG needs.
> >> I was wondering how we can confirm jitterentropy's kernel module was
> >> successfully loaded during boot so we can be sure it works on some
> >> platforms.
> > cat /proc/crypto | grep jitter
> >> Do you know if it should be functional on the Xen hypervisor where Linux
> >> does not have full control over bare-metal?
> > Yes, definitely. Besides, the Jitter RNG will not initialize if it finds
> > that the platform does not provide the correct properties for the RNG.
> > The Jitter RNG has also a runtime check. If that runtime check identifies
> > platform failures, you will see that in dmesg :-)
> > Though, please note that the Jitter RNG in the kernel ONLY seeds the
> > kernel
> > DRBG and NOT /dev/random or /dev/urandom. If you want to seed them, you
> > need either the jitterentropy-rngd (which seems to be currently tested)
> > or the latest version of rngd which contains the JitterRNG as one noise
> > source.
> Interesting. The kernel DRBG is synonymous with /dev/random in our
> non-expert minds. So is it correct to say jitterentropy-rngd's presence
> guarantees /dev/urandom will be correctly seeded? Or does it depend on
> service starting order?
This is all a sad state of affairs. But getting changes into drivers/char/
random.c is very hard for different reasons. I have tried and even have a
complete replacement implementation at .
Whatever, the following is applicable:
- /dev/random, /dev/urandom and getrandom(2) is handled completely and
exclusively by drivers/char/random.c. /dev/urandom and getrandom(2) access a
ChaCha20-based PRNG. /dev/random is fed by a SHA-1 based PRNG.
- the in-kernel crypto API has an RNG framework that provides a DRBG. This
DRBG is used for in-kernel crypto API purposes. It may be accessed from user
space via AF_ALG . Yet, this is not accessible from /dev/random, /dev/
urandom or getrandom. The DRBG uses the in-kernel JitterRNG to seed itself.
The jitterentropy-rngd would update the entropy of /dev/urandom, /dev/random
You want the jitterentropy-rngd to start as early in the boot cycle as
possible, certainly before any crypto daemons like SSH or TLS servers are
brought online. Maybe the systemd service file provided with the
jitterentropy-rngd should help?
> >> cc/ our mailing list do our users can benefit.
> > Ciao
> > Stephan
More information about the Whonix-devel