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

[Arnold Reinhold]

On Sat, 26 Nov 2016 12:52 David Johnston wrote:

> On 11/25/16 12:55 PM, Arnold Reinhold wrote:
> 
>> 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.
> This has been addressed multiple times on this list so once again:
> 
> The raw access mode is disabled on production parts. This is because it 
> would be an attack vector. Log into a VM in a cloud machine and put the 
> RNG into raw mode and other processes in other VMs would then be getting 
> unwhitened data while thinking they were getting the output of a CSPRNG 
> (RdRand) or an ENRBG (RdSeed).
> 
> If we enabled ring 0 processes to put the shared RNG in raw mode to 
> satisfy the curiosity of people on this list we would be enabling an 
> attack on most users. Also we would be violating the FIPS140-2 and 
> SP800-90 requirements. The quality of the raw data is tested internally 
> to the DRNG with the algorithms we have published.
> 
> Feel free to talk to NIST about adding things to their specs to enable 
> raw access in while simultaneously in a FIPS context and a cloud context.

First let me say that I believe the people at Intel who designed RdRand were working sincerely and produced a design of top quality. I also believe it received a reasonable amount of peer review, at least internally. My concern is the possible existence of a secret mode that substitutes a deterministic or partially deterministic bitstream for the output RdRand would have produced under the advertised design. The value of such a mode to a cryptanalyst who knew how to use it is beyond dispute. It is inconceivable to me, and I suspect most people on this list, that the NSA would not at least attempt to have such a mode included in some or all of these chips. Doing so could have been approved by a patriotic senior management, required under a National Security Letter (with gag order), or, less likely, implemented by a mole in the Intel organization. The knowledge that such a mode exists would be closely guarded, known by a minimal number of people. If such a mode does not exist, that fact could be asserted by only the even tinier handful of people who have access to all of NSA's exceptionally guarded compartments (I hope there are only a handful).

So asking for access to un-whitened entropy is not a question of curiosity, nor is this an attack on the integrity of the people who designed RdRand. It is a request for a mechanism that could restore trust in the on-board RNG. Your argument does convince me that a mode to simply turn off whitening would not be wise, but it does not rule out a separate RdRandRaw or RdSeedRaw instruction. 

> Feel free to talk to NIST about adding things to their specs to enable 
> raw access in while simultaneously in a FIPS context and a cloud context.

I have commented at length on the -90C revision (tho not on this point) and was told explicitly that NIST specs and FIPS standards reflect the interests of the U.S. government and not necessarily the public at large. And I see nothing in those specs that prevent a separate access to raw entropy.

So my answer to this thread's original question is that if your threat model does not include the NSA and other state actors who may have gained access to a possible secret DRNG mode, use of RdRand by itself is likely ok. If not, its output should be mixed with other sources of entropy.

Arnold Reinhold