Fallback source of entropy

[dhardy]

This issue is a tracker for the topic providing an alternative entropy source in case OsRng fails.

Motivation: rust-random#180

Existing work: #21, rust-random#181

---

• EntropyRng provides part of the switching mechanism
• JitterRng provides one fallback
• we may still allow applications to provide another entropy source, especially useful for embedded

[dhardy]

It would be nice to see:

• An implementation of the jitterentropy library in Rust as a candidate for a good fallback entropy source
• Further investigation of the requirements for clock-based generators
• Good entropy estimates for various generators

[burdges]

I'd think this should stay in an external crate. At least folks should not need to roll their own OsRng to avoid this.

[dhardy]

To avoid it? Obviously OsRng should only return entropy from the OS; one shouldn't have potentially weak entropy used in cryptography without explicitly opting in to it.

Should it be external? Possibly. Initially I thought it would just be a tiny bit of code; now, I'm not so sure.

[burdges]

Right, I'm not worried if we're not talking about modifying OsRng itself, thanks. I'd think the linker strip any mutable statics used or whatever if not used, so no worries about where you put it. :)

[dhardy]

#28 implements JitterRng.

This RNG has a bunch of diagnostics to check that it can actually get good entropy from the clock. In part this is necessary because the code can loop forever if time deltas are constant, but it brings up another question:

• Do we want a low-quality and a high-quality clock-based entropy source?
• Do we want very weak entropy vs having nothing?

Possibly the best option is to have JitterRng as a high-quality entropy source (possibly useful on some systems without other entropy source) plus another generator as a weak entropy source for thread_rng (as a second fall-back, should both OsRng and JitterRng fail).

[pitdicker]

Another option is to make the number of rounds JitterRng uses configurable. Now it does 64 rounds of entropy collection for 64 bits. This is very conservative, something like 40 rounds covers desktop processors and servers. Just let it perform something like 8 rounds if a low-quality source is ok.

I also plan to make the timer test run only once, and store the result with lazy_static. Now initializing it takes about as much time as generating 8~10 u64s, and then 1 u64.

What do you propose to use as a third fallback source? I would say that if the timer is not good enough for running JitterRng, is is certainly not good enough for a simpler scheme. RDRAND is an option though.

[dhardy]

Since #54 my branch uses JitterRng as a fallback, so I guess this is solved (unless there's a reason this needs to change).

[burdges]

Just fyi https://aws.amazon.com/blogs/opensource/better-random-number-generation-for-openssl-libc-and-linux-mainline/

[dhardy]

The design of the s2n generator talked about above ↑ sounds really good, in particular the three levels of protection against leaking private random numbers (3 may be overkill, but we don't currently have any of these). We should look into this, whether all via thread_rng or using other functions.

Related, we may want to allow users to inject their own source of entropy too (for WASM and no_std targets where we currently don't have any source of entropy). (We mentioned this here.)

Also see #59.

[dhardy]

Much of this was implemented; I opened a separate issue regarding s2n strategies