[Cryptography] Use of RDRAND in Haskell's TLS RNG?

[Arnold Reinhold]

On 11/23/2016 02:23 AM, Darren Moffat wrote:
> What is a "proper audit" and why do you think that Intel hasn't done that
> already ? What more find they (or any chip designer/builder) do to convince
> you?

In addition the need for a proper published audit that bear suggested, the most glaring defect in the Intel design is the lack of access to the un-whitened random bits. Adding a mode that bypassed the whitener would have been simple. Statistical analysis of the raw bit stream can provide ongoing assurance that the RNG is doing what it says. Likely there will be correlations between raw bit statistics and external parameters such as chip temperature and supply voltage. Of course it is possible for a deterministic generator to mimic such variations, but it would have to have a relatively large footprint on the die compared to simply using the whitener in a feedback mode or similar mischief. 

Subversion of the RNG is one of the best methods for compromising a cryptographic system. It offers an attack for any algorithm that relies on that RNG and requires no data channel back to the attacker. While there are lots of ways to create good random sources, there are very few ways to audit the results. I can’t see any good reason why a hardware RNG should include a whitener. The benefit of avoiding the need to whiten in software is far outweighed by the impenetrable barrier a good whitener presents to any statistical audit of RNG behavior. 

Separation of responsibilities is a basic security concept. A well run accounting department does not let the person who signs checks have access to the blank forms. Similarly, whitening should always be separate from random bit creation. A RNG that only offers whitened output must always be suspect. 

Arnold Reinhold