Bug#927972: jitterentropy_rng.ko never loads
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."
Bug#927972: jitterentropy_rng.ko never loads
Control: retitle -1 set jitterentropy_rng.ko to built-in Control: reassign -1 src:linux On Tue, 30 Apr 2019 11:38:00 + Patrick Schleizer < adrela...@riseup.net > 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? Dear kernel maintainers, I apologise for the ping-pong, but this bug is now a request from the reporter to change the kernel module to built-in, so reassigning to src:linux : On Fri, 2019-04-26 at 16:47 +, proc...@riseup.net wrote: > OK. I found out this is not a problem on Fedora stations likely > because > they have the module built with 'y' instead of 'm'. Can you please > add > this to your next point release? I guess it might make sense on the cloud images, although I have not nearly enough knowledge and no strong opinions on the matter. Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#927972: jitterentropy_rng.ko never loads
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?
Bug#927972: jitterentropy_rng.ko never loads
On 4/26/19 4:55 PM, Luca Boccassi wrote: > On Fri, 2019-04-26 at 16:47 +, proc...@riseup.net wrote: >> OK. I found out this is not a problem on Fedora stations likely >> because >> they have the module built with 'y' instead of 'm'. Can you please >> add >> this to your next point release? > If you want the module to always load, you can simply list it in > /etc/modules - have you tried that? > Update: According to jitter's author Stephan Mueller, the kernel module has no effect on the quality of entropy injected in /dev/?random (it only handles the kernel DRBG). /dev/?random entropy is only in the domain of the userspace jitternetropy-rngd service which already works for us: Quote from Stephan: "As I tried to outline in the previous email: the /dev/random or /dev/urandom will NOT benefit from the in-kernel Jitter RNG. Only the user space jitterentropy-rngd from user space would inject entropy into /dev/random / / de/urandom. Therefore, I do not think that inserting the jitterentropy KO will help you for your goal." You can close both tickets I guess. Thanks for everyone's input. signature.asc Description: OpenPGP digital signature
Bug#927972: jitterentropy_rng.ko never loads
On 4/26/19 4:55 PM, Luca Boccassi wrote: > On Fri, 2019-04-26 at 16:47 +, proc...@riseup.net wrote: >> OK. I found out this is not a problem on Fedora stations likely >> because >> they have the module built with 'y' instead of 'm'. Can you please >> add >> this to your next point release? > If you want the module to always load, you can simply list it in > /etc/modules - have you tried that? > Yes I've added a conf at /etc/modules-load.d/jitterentropy_rng.conf and it loads as expected. My suggestion was so that it would work in general on a default system for users who don't know this is needed for the jitter service to be effective. signature.asc Description: OpenPGP digital signature
Bug#927972: jitterentropy_rng.ko never loads
On Fri, 2019-04-26 at 16:47 +, proc...@riseup.net wrote: > OK. I found out this is not a problem on Fedora stations likely > because > they have the module built with 'y' instead of 'm'. Can you please > add > this to your next point release? If you want the module to always load, you can simply list it in /etc/modules - have you tried that? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#927972: jitterentropy_rng.ko never loads
OK. I found out this is not a problem on Fedora stations likely because they have the module built with 'y' instead of 'm'. Can you please add this to your next point release?
Bug#927972: jitterentropy_rng.ko never loads
On 4/25/19 8:21 PM, Ben Hutchings wrote: > Control: reassign -1 jitterentropy-rngd > Control: severity -1 wishlist > > There is no dependency between the user-space daemon and the kernel > module. And I don't see any kernel bug here, but this might be a > wishlist item for the user-space package. > > Ben. > I see. Thanks Ben. Is there anything you guys can do at your end to force this particular module to load on all hosts running a kernel that supports it? Reason is crypto entropy is exceptionally important. Thanks. signature.asc Description: OpenPGP digital signature
Bug#927972: jitterentropy_rng.ko never loads
Control: reassign -1 jitterentropy-rngd Control: severity -1 wishlist There is no dependency between the user-space daemon and the kernel module. And I don't see any kernel bug here, but this might be a wishlist item for the user-space package. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#927972: jitterentropy_rng.ko never loads
Package: linux-image-amd64 Version: 4.19+104 Severity: important Dear Maintainer, As part of my work on a downstream privacy distro, I tested jitternentropy-rngd while integrating it and discovered the complementing kernel module jitterentropy_rng.ko never loads on boot as it is supposed to when the userspace jitterentropy daemon is installed. As a VM based OS a reliable entropy source that guarantees /dev/urandom is safely seeded is a priority. To test if it works one would see the signs described by the jitter dev Stephan Mueller [0]. I;ve confirmed that oddly no dmesg messages appear and the userspace service churns along fine despite the module silently never loading. Please try to fix this when possible. I will report this problem against the jitter package too. TIA [0] https://www.whonix.org/pipermail/whonix-devel/2019-April/001365.html [1] https://www.whonix.org/pipermail/whonix-devel/2019-April/001366.html
