Bug 1706917

Summary: NSS should implement continuous random test on it's seed data or use the kernel AF_ALG interface for random
Product: Red Hat Enterprise Linux 8 Reporter: Simo Sorce <ssorce>
Component: nssAssignee: nss-nspr-maint <nss-nspr-maint>
Status: CLOSED CURRENTRELEASE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: low Docs Contact:
Priority: high    
Version: 8.1CC: cww, dueno, hkario, rrelyea, snagar, tmraz, toneata
Target Milestone: rcKeywords: Triaged, ZStream
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1725059 (view as bug list) Environment:
Last Closed: 2019-08-05 08:16:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1591648, 1725059    

Description Simo Sorce 2019-05-06 13:59:06 UTC
FIPS requires continuous tests of the input to the libraries CSPRNG but the kernel getrandom() (or /dev[u]random) interface does not do it.

Available options is to implement tests in the library or use the kernel AF_ALG DRBG source which wil have these tests implemented in kernel.

Comment 1 Bob Relyea 2019-05-13 20:55:29 UTC
Updating the comment to make it more clear to developers what need the CSPRNG check. NSS's PRNG already has a continous random number check. The issue is NSS gets it's seeding from the kernel, which only does the check when the AF_ALG DRBG flag is set.

The latter is preferable, because doing the check in NSS on the random output won't detect a stuck PRNG if NSS doesn't get data in the blocksize of the underlying kernel PRNG.

bob

Comment 2 Simo Sorce 2019-05-13 21:03:42 UTC
What the bug is asking is to either keep using the current interfaces as a source of random but add checks in the code that no two consecutive values repeat, or to change NSS to use the kernel AF_ALG interface (via libkcrypto or by direct access) instead as a source of random, because the kernel's interface will have checks there.