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