Re: Lightweight support for instruction RNGs

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 22 Dec 2015 10:50:37 -0800
    From:        Alistair Crooks <agc%pkgsrc.org@localhost>
    Message-ID:  <CAN5gJXoCNTv0rmXPmpn1s79Q4JWPiKSV78OB_4YNRhXmu93EEA%mail.gmail.com@localhost>

First, I really think that continually adding more lists to this "conversation"
helps nothing, so I have pruned the list for this reply to tech-security and
omitted all the rest (nothing here has anything to do with any particular
ports, or after the first couple of messages, the kernel, and the discussion
is not really about crypto algorithms.)

I have noticed others attempting to do the same, but without emphasising
the point...

For some substance for this message ...

Alistair, this article (you referenced) ...

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

really supports Thor's point, not yours.   It makes it clear that if
the final hashing stage of the rng had been secure, then regardless of
the flawed input, everything would have been safe.

The problem there was that that wasn't true ... the analogy for NetBSD
would be if there was a known or discovered flaw in the final hashing scheme.
Then there would truly be a problem.

Absent that, it does not seem that the inputs to the hash function matter
much, as long as they are unknown - and unless the new source somehow makes
the older ones less unknown, it cannot possibly hurt I would have thought,
the worst it can be is a waste of time if it fails to add anything useful.

kre