Re: Lightweight support for instruction RNGs

Yeah, we keep coming back to this asssumption that nothing can go
wrong with the random output in userland because it is passed through
whitening filters on its way. The analysis of the recent Juniper
backdoor should give you an idea of why relying on that kind of
reasoning is unsound - Juniper had multiple levels of whitening in
their product, and have still had to go through a particularly
embarassing episode. It's worrying to me that we've had to bolt the
stable door once already in this area.

http://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault


On 21 December 2015 at 16:38, Thor Lancelot Simon <[email protected]> wrote:
> On Mon, Dec 21, 2015 at 09:28:40AM -0800, Alistair Crooks wrote:
>> I think there's some disconnect here, since we're obviously talking
>> past each other.
>>
>> My concern is the output from the random devices into userland. I
>
> Yes, then we're clearly talking past each other.  The "output from the
> random devices into userland" is generated using the NIST SP800-90
> CTR_DRBG.  You could key it with all-zeroes and the statistical properties
> of the output would differ in no detectable way* from what you got if
> you keyed it with pure quantum noise.
>
> If you want to run statistical tests that mean anything, you need to
> feed them input from somewhere else.  Feeding them the output of the
> CTR_DRBG can be nothing but -- at best -- security theater.
>
>  [*maybe some day we will have a cryptanalysis of AES that allows us to
>    detect such a difference, but we sure don't now]
>
> Thor
>