[Cryptography] RSA recommends against use of its own products.

[ianG]

Hi Jerry,

I appreciate the devil's advocate approach here, it has helped to get my 
thoughts in order!  Thanks!

My conclusion is:  avoid all USA, Inc, providers of cryptographic 
products.  Argumentation follows...


On 24/09/13 19:01 PM, Jerry Leichter wrote:
> On Sep 23, 2013, at 4:20 AM, ianG <iang at iang.org> wrote:
>>>> RSA today declared its own BSAFE toolkit and all versions of its
>>>> Data Protection Manager insecure...
>>
>> Etc.  Yes, we expect the company to declare itself near white, and the press to declare it blacker than the ace of spaces.
>>
>> Meanwhile, this list is about those who know how to analyse this sort of stuff, independently.  So...
> Indeed.
>
>>> ...  But they made Dual EC DRBG the default ...
>>
>> I don't see a lot of distance between choosing Dual_EC as default, and the conclusion that BSAFE & user-systems are insecure.
> The conclusion it leads to is that *if used in the default mode*, it's (well, it *may be*) unsafe.


Well, defaults being defaults, we can assume most people have left it in 
default mode.  I suppose we could ask for research on this question, but 
I'm going to guess:  most.  Therefore we could say that BSAFE is 
"mostly" unsafe, but as we don't know who is using it in default mode, 
I'm sure most cryptography people would agree that means "unsafe, period."


> We know no more today about the quality of the implementation than we did yesterday.  (In fact, while I consider it a weak argument ... if NSA had managed to sneak something into the code making it insecure, they wouldn't have needed to make a *visible* change - changing the default.  So perhaps we have better reason to believe the rest of the code is OK today than we did yesterday.)


Firstly, this is to suggest that quality of implementation is the issue. 
  It isn't, the issue is whether the overall result is safe -- to 
end-users.  In this case, it could be fantastic code, but if the RNG is 
spiked, then the fantastic code is approx. worthless.

Reminds me of what the IRA said after nearly knocking off Maggie Thatcher:

     "Today we were unlucky, but remember we only have to be lucky once.
     You will have to be lucky always."

Secondly, or more widely, if the NSA has targetted RSA, then what can we 
conclude about quality of the rest of the implementation?  We can only 
make arguments about the rest of the system if we assume this was a 
one-off.  That would be a surprising thing to assume, given what else we 
know.


>> The question that remains is, was it an innocent mistake, or were they influenced by NSA?
> a)  How would knowing this change the actions you take today?


* knowing it was an innocent mistake:  well, everyone makes them, even 
Debian.  So perhaps these products aren't so bad?

* knowing it was an influenced result:   USA corporations are to be 
avoided as cryptographic suppliers.  E.g., JCE, CAPI, etc.

Supporting assumptions:

1. assume the NSA is your threat model.  Once upon a time those 
threatened were a small group of neerdowellers in far flung wild 
countries with exotic names.  Unfortunately, this now applies to most 
people -- inside the USA, anyone who's facing a potential criminal 
investigation by any of the USA agencies, due to the DEA trick.  So most 
of Wall Street, etc, and anyone who's got assets attachable for ML, in 
post-WoD world, etc.  Outside the USA, anyone who's 2 handshakes from 
any neerdowellers.

2. We don't as yet have any such evidence from non-USA corps, do we? 
(But I ain't putting my money down on that...)

3. Where goes RSA, also follows Java's JCE (recall Android) and CAPI. 
How far behind are the rest?

http://www.theregister.co.uk/2013/09/19/linux_backdoor_intrigue

4. Actually, we locals on this list already knew this to a reasonable 
suspicion.  But now we have a chain of events that allows a reasonable 
person outside the paranoiac security world to conclude that the NSA has 
corrupted the cryptography delivery from a USA corp.

http://financialcryptography.com/mt/archives/001446.html


> b)  You've posed two alternatives as if they were the only ones.  At the time this default was chosen (2005 or thereabouts), it was *not* a "mistake".  Dual EC DRBG was in a just-published NIST standard.  ECC was "hot" as the best of the new stuff - with endorsements not just from NSA but from academic researchers.  Dual EC DRBG came with a self-test suite, so could guard itself against a variety of attacks and other problems.  Really, the only mark against it *at the time* was that it was slower than the other methods - but we've learned that trading speed for security is not a good way to go, so that was not dispositive.


True, 2005 or thereabouts, such a "story" could be and was told, and we 
can accept for the sake of argument it might not have been a "mistake" 
given what they knew.

That ended 2007.  RSA was no doubt informed of the results as they 
happened, because they are professionals, now conveniently listed out by 
Mathew Greene:

http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html?

At that point the story unravels.  At that point, many would have 
concluded to change default, or even dropped the collector entirely.  If 
they were doing their job!  At that point, RSA did not change the 
default, and we move from "innocent mistake" to "negligence".


> Since we know (or at least very strongly suspect)


We know, to as great an extent as we ever can.  The evidence problem has 
to be seen in context.  Here is what we know so far:


1. the NSA will never ever give us the evidence, and it will even lie to 
a court about it.  They will go to the grave rather than admit it.
2. the NSA has perverted the standards process.
3. the NSA has perverted a commercial supplier of cryptography.
4. the NSA has a pattern and practice of repeated attempts at the above.
5. they are the spooks -- they wrote the book on deception.
6. a perverted supplier will always put a positive spin on it.  It's 
their livelihood, after all.  Can't blame them for trying to survive.


I suggest the above are facts, but anyone is free to establish their own.

In such a context, resting on lack of evidence of the "smoking gun" 
variety, and applying the legal theory of "guilty until proven innocent" 
is inappropriate.  I feel we could get away with that if the job is 
marketing, but inappropriate and negligent if the job is security.


> that the addition of Dual EC DRBG to the NIST standards was influenced by NSA, the question of whether RSA was also influenced is meaningless:  If NSA had not gotten it into the standard, RSA would probably not have implemented it.


Well, obviously this was a 2 phase story.  Either phase can fail, thus 
rendering the result fail.  But to conclude that RSA's part as 
meaningless is somewhat weird, that's the essence of finger-pointing. 
They had a choice, and they had a duty of care.  Pointing at NIST 
doesn't change that.


> If you're asking whether NSA directly influenced RSA to make it the default - I doubt it.  They had plenty of indirect ways to accomplish the same ends (by influencing the terms of government purchases to make that a requirement or a strong suggestion) without leaving a trail behind.


According to the information seen, and what I've been told informally in 
answer to my questions, that is exactly what happened:  Under influence 
of a large government contract, RSA was directly influenced 
("encouraged") to make Dual_EC into the default.  "For the benefit of us 
all."

Of course, there is no smoking gun, and Lucky's characterisation of the 
NSA paying $10m to spike the RNG could be said to be inaccurate and 
journalistic.  But not a completely wrong picture.

The NSA isn't that stupid.  Should we be?


>> We don't have much solid evidence on that.  But we can draw the dots, and a reasonable judgement can fill the missing pieces in.
> And?  It's cool for discussion, but has absolutely nothing to do with whether (a) BSAFE is, indeed, safe if you use the current default (we assume not, at least against NSA); (b) BSAFE is safe if you *change* the default (most will likely assume so); (c) users of BSAFE or BSAFE-based products should make sure the default is not used in products they build or use (if they're worried about NSA, sure) (d) implementors and users of other crypto libraries should change what they are doing (avoid Dual EC DRBG - but we already knew that).


 From the above facts, can we conclude either that

    (i) we have found the *one and only one* flaw,

or, are we wiser to conclude that

    (ii) we found /one of the/ flaws?

As to your questions:

(a) we cannot conclude BSAFE is safe, or not safe.  We never could, nor 
can we now, for this or any other product.  What we can ask is how much 
safer or less safe it is, now that we know what we know.

Which is to say, there are no absolutes, and the framing of the question 
as an absolute is a trap.

We can only analyse BSAFE in terms of options -- would it be (for 
example) now safer to switch to another provider?   Building on the 
theme of alternates, according to NIST records, these use Dual_EC:

RSA, Thales, Catbird, McAfee, Cummings, OpenSSL, ARX, Certicom, 
RIM/Blackberry, Mocana, Microsoft, Cisco, Juniper, Blackberry, OpenPeak, 
Samsung, Symantec, Riverbed, CoCo, Kony, Lancope, SafeNet, SafeLogic, 
Panzura, GE Healthcare.

http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html

(b) If we assume one and only one flaw, then, turning off the default 
Dual_EC is "safe".

(c) If we assume one and only one flaw, sure.

(d) Well, and there we have it.  If we already knew not to use Dual_EC, 
what to make of the current discussion?  One rule for RSA, one for others?



I think the conclusion is reasonable:  Avoid all USA cryptographic 
providers.  I guess that will cause some to be upset, but if they are 
upset, I'd ask how we can establish some reasonable judgement over the 
above questions, and specifically, why we can't conclude that all 
sizable targets within USA, Inc are targetted for perversion by the NSA?



iang