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 <i...@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...

...  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 

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?


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.


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:


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.


(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?


The cryptography mailing list

Reply via email to