Bug#927972: jitterentropy_rng.ko never loads

["procmem@riseup.net" <procmem@riseup.net>]

On 4/30/19 11:38 AM, Patrick Schleizer wrote:
> On https://www.whonix.org/pipermail/whonix-devel/2019-April/001371.html
> its developer wrote:
>
>> [...]
>> - 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.
>> [...]
> Better entropy for in-kernel crypto API purposes sounds good as a
> general security enhancement.
>
> Fedora enables this kernel module by default, too.
>
> Does this sound like a good idea to enable loading this kernel module by
> default in Debian?
>
Stephan confirms that the Kernel DRBG is also important for crypto
operations that don't use /dev/random like the ECC cipher and much more.
I think it is important to revisit this in that case and add the jitter
module to the initramfs:


Stephan:

"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."

"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."