Am Mittwoch, 23. Juni 2021, 19:00:29 CEST schrieb James Morris: Hi James, > On Wed, 23 Jun 2021, Stephan Mueller wrote: > > > These changes replace the use of the Linux RNG with the Jitter RNG, > > > which is NIST SP800-90B compliant, to get a proper entropy input and a > > > nonce as defined by FIPS. > > > > Can you please help me understand what is missing in the current code > > which > > seemingly already has achieved this goal? > > The advice we have is that if an attacker knows the internal state of the > CPU, then the output of the Jitter RNG can be predicted. Thank you for the hint. And I think such goal is worthwhile (albeit I have to admit that if an attacker is able to gain the internal state of a CPU, I would assume we have more pressing problems that a bit of entropy). Anyways, the current code does: - in regular mode: seed the DRBG with 384 bits of data from get_random_bytes - in FIPS mode: seed the DRBG with 384 bits of data from get_random_bytes concatenated with 384 bits from the Jitter RNG If I understand the suggested changes right, I would see the following changes in the patch: - in the regular case: 640 bits from get_random_bytes - in FIPS mode: 256 bits of data from get_random_bytes concatenated with 384 bits from the Jitter RNG So, I am not fully sure what the benefit of the difference is: in FIPS mode (where the Jitter RNG is used), the amount of data pulled from get_random_bytes seems to be now reduced. Maybe I miss a point here, but I currently fail to understand why the changes should be an improvement compared to the current case. Ciao Stephan
