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

[Stephan Mueller]

Am Donnerstag, 2. Mai 2019, 05:44:26 CEST schrieb procmem at riseup.net:

Hi,

> On 5/2/19 8:09 AM, Stephan Mueller wrote:
> > Am Dienstag, 30. April 2019, 13:41:00 CEST schrieb Patrick Schleizer:
> > 
> > Hi Patrick,
> > 
> >> Hello Stephan,
> >> 
> >> thank you for all your kernel work and answering to us here, appreciated!
> >> 
> >> On https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927972 I asked
> >> Debian kernel maintainers to consider enabling the jitter kernel module
> >> by default.
> >> 
> >> Would you wish to share your thoughts on this?
> > 
> > I looked through the bug report. The message #41 effectively summarizes
> > all
> > very clearly and derives the right conclusions.
> > 
> > So, the jitterentropy kernel module is only used by the kernel DRBG. And
> > it
> > will load the jitterentropy kernel module automatically considering that
> > the module name is the same as the cipher name "jitterentropy_rng". Of
> > course, this only applies if the kernel module is available in the
> > execution environment (like the initramfs) and the DRBG is initialized
> > during that time.
> > 
> > Thus, I am not sure I can contribute more to the bug thread.
> 
> I guess asked another way, Patrick is wondering what the problems of a
> weak kernel DRBG would cause?
> 
> We know weak /dev/?random is catastrophic, but it was news to us that
> the in-kernel DRBG has no connection to it. So we want to know if this
> is so bad too that it warrants forcing the module.

Always assume that a weak RNG is bad. The DRBG is used for kernel crypto API 
for generating keys and other data. For example, the ECC key generation uses 
the DRBG and NOT the get_random_bytes (the /dev/urandom in-kernel equivalent). 
There are quite a number of other use cases.

I know, it is unfortunate that we have 2 RNGs in the kernel. But a 
consolitation approach I offered at [1] was not considered.

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

Ciao
Stephan