John Gilmore On How The NSA Sabotaged A Key Security Standard
from the betrayal-of-trust dept
In Bruce Schneier's uplifting call to fix the Internet in the wake of key technologies being subverted by the US government, one of the things he asks engineers to do is to come forward with detailed information about how the NSA did that:
We need to know how exactly how the NSA and other agencies are subverting routers, switches, the internet backbone, encryption technologies and cloud systems. I already have five stories from people like you, and I've just started collecting. I want 50. There's safety in numbers, and this form of civil disobedience is the moral thing to do.
Although not directly answering that call, EFF co-founder John Gilmore has written a fascinating short post about what he noticed happening on an IETF standards committee drawing up the important IPsec standard:
NSA employees participated throughout, and occupied leadership roles in the committee and among the editors of the documents
Needless to say, it was never simplified. Gilmore also reports what happened elsewhere:
...
Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto.
...
The resulting standard was incredibly complicated -- so complex that every real cryptographer who tried to analyze it threw up their hands and said, "We can't even begin to evaluate its security unless you simplify it radically".In other circumstances I also found situations where NSA employees explicitly lied to standards committees, such as that for cellphone
encryption, telling them that if they merely debated an actually-secure protocol, they would be violating the export control laws unless they excluded all foreigners from the room (in an international standards committee!).
Of course, this remains at the anecdotal level. But if Schneier gets his 50 NSA stories, we should start to have a much clearer picture of what the agency has been up to -- and how to stop it happening in the future.
Follow me @glynmoody on Twitter or identi.ca, and on Google+
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: backdoors, encryption, ietf, john gilmore, nsa, sabotage, standards, surveillance
Reader Comments
Subscribe: RSS
View by: Time | Thread
Kill them and take their stuff. 'Tis the Olde Viking way, and it seems apropos now.
[ link to this | view in chronology ]
No sarcasm today
As memos noted, citizens are the enemy here. So I say we MUST prevent all government agencies from influencing the design of any security infrastructure. They are immediately ineligible and suspect. The design must be elegant, simple to understand by a reasonable person with security knowledge. The source open so flaws can be detected and fixed. The design needs to be such that current technology would take years to brute force an attack. We don't want to rely on OEM libraries since they are also suspect. That is no using standard or certified libraries, since certification means endorsed by the enemy. All appliances such as switches and routers, telephony, etc. all need the firmware re-written.
Unfortunately we won't be told what encryption is safe, so we must assume none of it is. Further, we need to adopt an update strategy every few years and change the basic algorithm, even if it is strong, merely to ensure the current method has not been compromised.
[ link to this | view in chronology ]
Re: No sarcasm today
[ link to this | view in chronology ]
Re: Re: No sarcasm today
[ link to this | view in chronology ]
Re: No sarcasm today
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
http://en.wikipedia.org/wiki/P ublic-key_cryptography
[ link to this | view in chronology ]
Re: Re: No sarcasm today
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Of FFS..
Talk about backwards engineering.
[ link to this | view in chronology ]
Re: Of FFS..
Good job, NSA!
[ link to this | view in chronology ]
Next relevations in (redacted)
Great job guys and gals...
[ link to this | view in chronology ]
Security starts a home
i don't think there is any point in discussing un-authorized programming unless we are using open-source software ( I'm using Linux/Mint )
i tend to agree with Snowden -- nothing wrong with encryption that we have -- e.g. GnuPG -- implemented properly
he means on a secure host, and don't use "123456" for you password
the existing x.509 and CA structure is a mess: you are trusting everything your browser sends you -- and everything that mess has signed for
the First Thing a computer user should do is generate his key pair . once that's done he is in a position to vet and sign certificates . he won't need to do many of these -- just those that need to be secured -- e.g. NewEgg, Amazon, Credit Union, TurboTax, -- anyplace money is involved. you don't need https on a blog site. but you DO need GnuPG on your e/mail
Thunderbird/ENIGMAIL is one solution.
[ link to this | view in chronology ]