Re: Lightweight support for instruction RNGs

[<Paul_Koning%Dell.com@localhost>]

> On Dec 22, 2015, at 1:50 PM, Alistair Crooks <agc%pkgsrc.org@localhost> wrote:
> 
> 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

I don't think that's an accurate statement of the assumptions.  Instead, the assumption (at least my assumption) is that the particular whitening algorithm used in the NetBSD PRNG is a good one.  If that is valid, then the comments made about stirring in more entropy are also valid.

For all this to hold together, several things must be true.  The internal state of the PRNG must be inaccessible to attackers.  Enough of the entropy stirred into it must be unknown to the attackers (enough that guessing the resulting internal state is not feasible).  And finally, the mixing function must not be weak.

If some of these are not currently true, then the answer is to fix that.  Just as, for example, the fact that Juniper apparently violated requirement 3 means they had a problem, and that fixing the mixing function so requirement #3 does now hold is the answer.

	paul