lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Tue, 4 Aug 2020 17:57:00 -0700
From:   Marc Plumb <>
Subject: Flaw in "random32: update the net random state on interrupt and

Willy and Ted,

This commit has serious security flaws 

TL;DR This change takes the seed data from get_random_bytes and 
broadcasts it to the network, thereby destroying the security of 
dev/random. This change needs to be reverted and redesigned.

It is inefficient:

This function is called from an interrupt context, so there is no chance 
of a CPU switch, therefore the this_cpu_add function should be 
__this_cpu_add. This is a sign that the patch may have been rushed and 
may not be suitable for a stable release.

It is fixing the wrong problem:

The net_rand_state PRNG is a weak PRNG for the purpose of avoiding 
collisions, not to be unguessable to an attacker. The network PRNG does 
not need secure seeding. If you need a secure PRNG then you shouldn't be 
using the net_rand_state PRNG. Please reconsider why you think that this 
change is necessary.

It dramatically weakens dev/random:

Seeding two PRNGs with the same entropy causes two problems. The minor 
one is that you're double counting entropy. The major one is that anyone 
who can determine the state of one PRNG can determine the state of the 

The net_rand_state PRNG is effectively a 113 bit LFSR, so anyone who can 
see any 113 bits of output can determine the complete internal state.

The output of the net_rand_state PRNG is used to determine how data is 
sent to the network, so the output is effectively broadcast to anyone 
watching network traffic. Therefore anyone watching the network traffic 
can determine the seed data being fed to the net_rand_state PRNG. Since 
this is the same seed data being fed to get_random_bytes, it allows an 
attacker to determine the state and there output of /dev/random. I 
sincerely hope that this was not the intended goal. :)

Thank you

Powered by blists - more mailing lists