Bug 215481 - Deliberate reduction in the quality of entropy!
Summary: Deliberate reduction in the quality of entropy!
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 blocking
Assignee: other_other
Depends on:
Reported: 2022-01-11 12:01 UTC by Pavel Vasilyev
Modified: 2022-01-11 17:56 UTC (History)
2 users (show)

See Also:
Kernel Version:
Regression: No
Bisected commit-id:


Description Pavel Vasilyev 2022-01-11 12:01:39 UTC
Transition in the extract_buf (), drivers/char/random.c, function to use the BLAKE2 hash 

 The patches for the transition in the extract_buf(), drivers/char/random.c,
function to use the BLAKE2 hash lead to a decrease in the quality of the entropy.
 It can be seen that an unnecessary variable was deliberately used to hide 
the warnings from the compiler!


The 'salt' variable is not used anywhere. At the same time, data from the hardware sensor is assigned to it, that go into a vacuum.


The US Senate loves the new maintainer, I think he also works for the CIA or the NSA.

I propose to exclude him from minteners and study his work VERY carefully!
Comment 1 gregkh 2022-01-11 12:13:31 UTC
On Tue, Jan 11, 2022 at 12:02:37PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=215481
> Pavel Vasilyev (dixlor@gmail.com) changed:
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |gregkh@linuxfoundation.org

Please submit this through email to the proper developers and mailing
list, bugzilla is not used for this kernel component, sorry.
Comment 2 Theodore Tso 2022-01-11 16:27:50 UTC
This is also not a bug, since the variable in question (which is a *pointer*) was in fact very clearly used:

	 * If we have an architectural hardware random number
	 * generator, use it for BLAKE2's salt & personal fields.
	for (salt = (unsigned long *)&state.h[4];
	     salt < (unsigned long *)&state.h[8]; ++salt) {
		unsigned long v;
		if (!arch_get_random_long(&v))
		*salt ^= v; <=== salt is used here!

The goal of this hunk of code is to use RDRAND (or an equivalent CPU-provided RNG, if available) to mix into the 4 bytes located at state.h[4..7] using the XOR operation.

So before making claims about the new /dev/random co-maintainer, maybe you could "study very carefully" how the C programming language works first?

Note You need to log in before you can comment on or make changes to this bug.