[Whonix-devel] How to confirm jitter .ko was loaded

[Stephan Mueller]

Am Mittwoch, 24. April 2019, 20:36:01 CEST schrieb procmem at riseup.net:

Hi procmem,

> 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 [1].

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 [2]. 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 
and getrandom(2).

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?


[1] http://www.chronox.de/lrng.html

[2] http://www.chronox.de/libkcapi.html
> 
> >> cc/ our mailing list do our users can benefit.
> > 
> > Ciao
> > Stephan



Ciao
Stephan