undefined | Better HN

0 pointscolmmacc3y ago0 comments

Usually those libraries seed from a FIPS-validated hardware entropy source. AES-NI is a common one, it's validated on some chips, but other hardware vendors have others (we have a hardware RNG in the AWS Nitro System for example). FIPS specifies a handful of DRBG algorithms that can then be used. AES-CTR-DRBG is the most popular. That's definitely no the exact same algorithm as the ChaCha/Blake constructions in Jason's work. It's all rather carefully constructed and then checked as part of the validation process. This is probably the most common reason for userspace RNGs in cryptographic software.

0 comments

4 comments · 2 top-level

barsonme3y ago· 2 in thread

And some standards (like Common Criteria) actually require you to bring your own FIPS-validated CSPRNG, which effectively makes a userspace CSPRNG unavoidable.

I wasn't aware that FIPS required your _entropy source_ to be validated in order for your library to be validated, though. BoringSSL, for example, just reads from RDRAND, getrandom(2), or /dev/urandom. Maybe the OS/CPUs it's certified for all have FIPS-validated entropy sources?

cipherboy3y ago

Correct; after the newer seeding policies have taken affect, many have punted to the OS/app for seeding. See https://csrc.nist.gov/CSRC/media/projects/cryptographic-modu... -- the entropy input is plaintext via API, but still needs to be from an approved source via 90B I believe, so likely means their Android kernel is also certified or they maintain something like JitterEntropy for that.

The older e.g., 36xx series Google cert predates that requirement iirc, when you could seed from a non-FIPS kernel.

barsonme3y ago

Thanks. This explains the Common Criteria entropy assessment.

cipherboy3y ago

Every major Linux distro ships FIPS crypto libraries that seed from the Linux kernel; the source is available.

j / k navigate · click thread line to collapse