I'm working with a Cortex M0 SoC that integrate an "RNG" (not specifically claimed as TRNG), that is however claimed to be "suitable for encryption". It works using thermal noise measurements. Knowing the whole SoC retails for less than $10, my wonder is: if it is that good, why isn't it more widespread? In particular, why is it not available on the PC platform. I read that Intel used something similar, but it is no longer in use. Since the whole RNG should probably be analyzed to determine if it's any good, my question is more like: "Can thermal-noise be used for a TRNG ?"
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
5
A true random number generator (TRNG) usually consists of two components: an “unpredictable” source with high entropy, and a randomness extractor — a function which, when applied to the source, produces a result that is statistically close to the uniform distribution. When the output of a TRNG is used for cryptographic needs, it is prudent to assume that an adversary may have some (limited?) influence on the distribution of the high-entropy source.
Thus it takes a bit of work to obtain randomness and there are many pitfalls.
If it's done well, the statistical randomness of the extractor’s output can be proven, and is not based on any unproven assumptions, such as the security of cryptographic hash functions. On the other hand output rates may be slow, and ensuring outside physical influences are thwarted may not be always possible. Obviously thermal noise in a circuit may be influenced by other factors.
-
$\begingroup$ Why does it matter if your TRNG extractor relies on "unproven" cryptographic hash functions, if you're going to turn around and use the output as keys to "unproven" constructs like AES, RSA, HMAC, and ECDH? $\endgroup$ Commented Jun 9, 2017 at 3:15
-
$\begingroup$ @rmalayter Note that there is a difference between a security solution's strength and the assurance of it's strength. Proving cryptographic primitives' properties tells us something conclusively about both. A primitive in which similar properties are unproven may still be judged to be strong, but the assurance of the strength is necessarily weaker. Ideally both provable strength and hence definitive assurance of strength are wanted, but lacking that you take what you can. And the proof may still come in the future. $\endgroup$ Commented Jun 13, 2017 at 1:02
-
$\begingroup$ @user2460798 if you already rely on the the security of "unproven" primitives, there is little rational reason to avoid using say AES-256 or SHA-2 to whiten or extract data from a TRNG. If the primitive is insecure, all is lost anyway, so you might as well use the efficient primitives you've already implemented to condition the outputs of your TRNG. Which is why Intel and Microsoft chose AES as a TRNG extractor, and the Linux kernel chose SHA-1 and then ChaCha for conditioning
/dev/random. $\endgroup$ Commented Jun 13, 2017 at 1:49 -
$\begingroup$ @rma I'm not following your logic here. The first comment seems to be an argument against using a crypto hash function (which isn't being suggested in the answer). The second comment seems to be predicated on using "unproven" primitives, which again the answer isn't suggesting. Additionally, no one is saying any of the primitives are insecure, there are just not proven secure. I'd be interest in seeing links to Intel's and MS's choice to use AES. I can understand Intel's motivation - sell more cycles, but not MS's. $\endgroup$ Commented Jun 13, 2017 at 3:10
-
$\begingroup$ @user2460798 I was never arguing against using a hash or AES to "extract randomness", just pointing out that it was silly for kodlu to argue against relying on those primitives in his answer. From what I could find neither Intel or MSFT give a reason for their choices in their documentation, they just say something like "we use AES-CBC-MAC in accordance with NIST recommendation XXX". $\endgroup$ Commented Jun 13, 2017 at 13:27