dhardy
commented
5 years ago Thanks for splitting this out into a new issue.
At this point I can only agree that we should be cautious about considering JitterRng secure. Since it is only used as a backup entropy source and in practice should almost never be used, I don't think there is immediate cause for alarm; however, we should migrate away from using it.
I apologise for making you go to so much effort to convince me of this generator's weaknesses, but at least now we can make a clean decision for the whole project (i.e. never use this and possibly use RDRAND if a backup source is needed, rather than merely not include it in rand_os).
newpavlov
tarcieri
stouset
burdges
Splitting this discussion off from #681, I'd like to ask the question: is JitterRng secure enough to be considered a
CryptoRng?https://github.com/rust-random/rand/issues/681#issuecomment-455088763
JavaScript is just one example of a way an attacker could either influence the TRNG, or establish a covert channel to read its state. Cotenant VMs are another example. Even without a high precision timer, an attacker can still attempt to actively influence the RNG's output, and if they can establish any sort of signal that the attack is working, or starting to work, even if statistical, they can use that as part of a bidirectional feedback loop to tune the attack.
I read the "paper" on the design JitterRng is supposed to be based on,
jitterentropy-library:http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
Sidechannel attacks aren't discussed whatsoever, and don't seem to be considered. Quite the opposite. From section 7.1:
There have been a number of recent attacks which allow data to be exfiltrated across process boundaries via covert channels, namely Meltdown, Spectre, and Foreshadow. Variations of these attacks are being discovered on a frequent basis... the newest attack sidechannel attack on Intel CPUs, a sidechannel based on Integrated Performance Primitives, was just announced a few days ago.
It also non-chalantly cites HAVEGEd as related work, when it is somewhat notorious for failing to live up to its claims and being a potential source of poor random numbers, and is implicated in a PolarSSL CVE:
https://lwn.net/Articles/525459/ https://tls.mbed.org/tech-updates/security-advisories/polarssl-security-advisory-2011-02
Section 7.1.1 describes the general attack I had been discussing earlier in #681, but it makes a number of assumptions I don't think hold:
The analysis in this section is rather handwavy and assumes quite a bit about how an attack would work as if it were the only way. I see a real risks in how many of the inputs to JitterRng an attacker can potentially influence, and the potential number of ways the attacker could leverage minute statistical signals to tune these attacks.
Unfortunately, most papers on "TRNGs" I'm reading on ePrint describe purpose designed hardware RNGs, and though I have seen the term "TRNG" used for HAVEGEd-style entropy collectors in the past, I'm really beginning to wonder if this is a misnomer.
Regardless, here's a paper that puts forth a much more rigorous framework for evaluating TRNGs:
https://eprint.iacr.org/2009/299.pdf
And here's a paper that demonstrates a number of different attacks against hardware TRNGs, some of which are remotely exploitable:
http://eprints.whiterose.ac.uk/117858/7/micpro_IoT.pdf
Some of these attacks leverage the statistical techniques I was alluding to / guessing about earlier, and could potentially be adapted to something like
JitterRng.I think the burden of proof for security is ultimately on the RNG implementation. If I can't conceive of a practical attack, that doesn't make something secure, it means we don't know.
For a positive result, we'd need to prove or otherwise demonstrate properties of
JitterRng.Based on reading a few papers tonight, I think the state of affairs for these sorts of (pseudo-)TRNGs is in fact significantly worse than I had realized. If anyone has done a rigorous analysis of HAVEGEd-style software-based TRNGs, as opposed to hardware based ones, I've been unable to find it. The author of this library did not do such an analysis, and the quality of his paper is poor. Furthermore it does not seem to acknowledge or learn from past failures of HAVEGEd.
The security of these sorts of RNGs seems to rest entirely on an assumption: that modern CPUs are too noisy to be predicted, even when an attacker is able to directly influence their behavior via code running on the same CPU. I do not think this is a sound assumption.
I would consider the library
JitterRngis based on to be of questionable provenance, not learning from the mistakes of its predecessors, and fundamentally trying to do something I consider to be very scary: generate random numbers out of potentially attacker-controlled / influenced values, and also avoid leaking them through microarchitectural sidechannels.The main way we'd avoid the latter is by using a constant-time implementation which avoids secret-dependent branching, however branching on values
JitterRngintends to use as "random" secrets seems to be integral to the way it functions:https://github.com/rust-random/rand/blob/a7c2eae35e7d547bbe3b1ba766d9351f0c97eae8/src/rngs/jitter.rs#L634-L675
tl;dr:
JitterRngseems rather scary to me, and I personally do not consider it of high enough quality to be considered aCryptoRng, and would like to ensure it is not accidentally used in place of an OS-provided RNG in any of my cryptography projects consumingrand_os.