While developing software aiming for nist compliance, I’m having difficulty figuring out the “nist way of getting secure random numbers.” (For generating long-term secret keys)

The standard non-nist way to generate cspring trusted by security experts worldover is to simply feed a bunch of dirt poor quality rng sources like thermal sensors and interrupt timing (e.x. from network packets) into a secure hash like Blake or shake or sha2, which will avalanche the occasional truly random bit every so often into a quality stream of truly random numbers.

Nist makes no mention of this and goes so far in SP 800-90A-C as to restrict rng sources to tamper proof and require nonsensical rng testing.

As far as I can tell, none of the usual random sources like CryptGenRandom in Windows or /dev/urandom everywhere else can hold up beyond security level 1, so where do we get our random data from?

The most nist-compatible (yet still insane) approach I’ve been able to devise is having the admin hammer the keyboard during software install and collecting the timings until a table of all the timings to the nth-derivative of the table length contains as many unique entries as the security bit level (128, 192, 256), hashing these with nist-approved sha2hmac, and storing this for permanent reuse to nist-approved aes-ctr. The proof of this will be self tests using nist’s rng test suite and the validity of these self tests will be proven by one out of about a hundred user keyboard setups failing the rng tests (as is expected for any high quality rng fed to nist rng tests as imho the tests are stupid and nonsensible).

Is there a better alternative or how does one get nist-approved entropy when all of the system entropy sources use the latest, best, least-nist-compliant csprings?

(Also, don’t worry: I know about “nist-ready” uncertified bs and I promise this software won’t be one of then and I’m actually going to get it certified.)