[Cryptography] [RNG] /dev/random initialisation

[ianG]

On 31/10/13 06:28 AM, John Kelsey wrote:
> On Oct 30, 2013, at 2:09 PM, Jerry Leichter <leichter at lrw.com> wrote:
>
>> On Oct 30, 2013, at 8:29 AM, ianG <iang at iang.org> wrote:
>>> Do we see a multi-phase approach here?
>>>
>>> 1.  Limit the sources to FIPS-authenticated inputs.
>>> 2.  Limit the number of sources that can be used.
>>> 3.  Do a deal with all major suppliers of FIPS-authenticated inputs.
>>> 4.  Profit.
>>>
>>> This is looking like the same multi-pronged strategy that sunk DRBG_EC.
>> Maybe.  Or maybe we just see a misapplied reasonable principle that any input that could affect sensitive data must be authenticated.
>
> The part of the standard involving entropy sources isn't done yet, but when it is, RBGs really will have to ultimately be fed by an approved entropy source.  The alternative seems to be leaving people in the current situation, where there's more or less no way of knowing how much entropy is being collected, or where it's coming from.  If the entropy source is good, then the RBG should end up secure.


The assumption that a FIPS-approved entropy source is a good source is 
now challenged.

> The restriction on external sources of additional input is pretty obviously a misunderstanding--someone somewhere got confused between entropy source inputs (which need to come from some trusted entropy source) and additional inputs (which can come from anywhere).


If it is a misunderstanding, it's had larger than normal ramifications. 
  There have been many reports of dropping all external sources as a 
need to get approval.  It's the process?


> I'm not sure what that "do a deal with fips authenticated inputs"  bit is even supposed to mean.


The above should be read:  "do a deal with the vendors of FIPS-approved 
entropy sources."  (If there is any FIPS authentication, I assume that 
this is a commercial product that is sold for $$$ as otherwise there is 
little chance of covering the cost of FIPS.  Challenge?  Peter?  Ben?)

The process of the NSA, as apparently expounded in various press 
articles, is to go to these suppliers and ask in a sort of joking 
fashion, "hey, are you going to do a back door for me?"  If that 
conversation works out, isn't rejected, then the approach proceeds.  If 
the conversation is rejected, they back off.

(Insert normal business approaches here about priorities, government 
contracts, influence.)

I don't think anyone has published a definitive writeup on this process. 
  There are multiple confirmations of the above, in some sense or other. 
  Bruce Schneier mentioned he is collecting stories, he mentioned he 
already had several so I guess we can await a blog post on the stories.


> But this kind of nonsense doesn't have to make sense, it just has to be entertaining.


I understand that it is really tough to sort the tin-foil hatters from 
the serious folk.  E.g., I frequently got slapped down when I suggested 
to serious security and crypto people that Skype post-USA-sale could no 
longer be trusted.  Now we know it is fact;  the protocol was changed 
and opened up to server manipulation in or around 2008/2009.  USG 
influence started the moment Skype entered jurisdiction (although maybe 
not in the way that interests this group).

More tin-foil hattism revealed:

http://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html

It's really really hard when you work at a job where everyone's entire 
reputation is dependent on this question.


>> "Never attribute to malice what can be explained by incompetence."  One of the really bad things about the NSA's apparent attempts to subvert crypto is that it leads you to question this assertion.  We just have no way of knowing.
>
> That's true.  But it's also true that security is hard to get right.  Lots and lots of dumb policies and decisions have been accepted or imposed by people who thought they were doing something sensible, but were really making security weaker.  And the bit where people make up conspiracy theories to explain every such failure has zero chance of improving security.


Fertile ground for interventions, that is precisely the point.



The question probably comes down to:  do you believe that the NSA 
intervenes in the process?  If not, then you will tend to err on the 
side of incompetence, security being too hard for people, avoid 
committees, etc etc.

If you do believe that the NSA has and is interfering in the process, 
then all bets are off.  We have to establish a theory as to how, when, 
why, etc.

What's that theory?

Remember, intelligence community are the experts in interfering with 
processes;  it is their job to do it in other countries.  They've been 
doing it as a profession since the 1930s in USA, far longer in other 
countries.

We are the amateurs.  We are children compared to their capabilities. 
Interventions will always be explainable, and adults always know better.



Back to the topic:  my conclusion is to not accept the FIPS 
standardisation requirement that only FIPS sources be used, and to 
insist that an independent carefully designed source be added into the 
mix.  If that costs our FIPS compliance, then so be it.  Call it FIPS 
compatible and let the marketing dudes worry about it.



iang