FREAK, Logjam, DROWN All a Result of Weaknesses Demanded By US Gov't (csoonline.com) 70
itwbennett writes: You need look no further than the FREAK and Logjam attacks in 2015 and the DROWN attack announced just this week to get a sense of 'the dangers of deliberately weakening security protocols by introducing backdoors or other access mechanisms like those that law enforcement agencies and the intelligence community are calling for today,' writes Lucian Constantin. But this isn't a new problem. 'One approach [the government] used throughout the 1990s [to keep encryption under its control] was to enforce export controls on products that used encryption by limiting the key lengths, allowing the National Security Agency to easily decrypt foreign communications,' says Constantin. 'This gave birth to so-called 'export-grade' encryption algorithms that have been integrated into cryptographic libraries and have survived to this day.'
What about "Import Grade" (Score:4, Interesting)
The way around the stupid laws that do not protect anyone from anything, is to import crypto from outside the US that is better and more robust than the stupid crippled versions mandated by US Law.
Re:What about "Import Grade" (Score:4, Insightful)
Re:What about "Import Grade" (Score:4, Interesting)
No, but would you necessarily trust the US government either...
The difference is that the US government has more reason to spy on a random US citizen then a foreign government does, and are more likely to do something with the information.
If you're going to use something thats backdoored, better to have it backdoored by someone who has no interest in you.
Re: (Score:1)
Why on earth would the govt want to spy on you? You think some NSA nerd is sitting behind his star trek console watching your every move?
Re:What about "Import Grade" (Score:5, Informative)
Re: (Score:2)
Or a corporate overlord, or a socialist nutjob that is probably the best option due being too pussy to do what he wants to.
Re: (Score:2)
What's images got to do with this?
Re:What about "Import Grade" (Score:4, Insightful)
Re: (Score:1)
You're a moron. IT'S NOT ABOUT THE NSA SPYING ON YOU. It's about the NSA opening up holes in encryption that OTHERS use to spy on you ALSO.
Re: (Score:2)
You know for sure he wasn't the victim of so-called "LOVEINT"?
NSA does have to watch at least someone, or else it would just be money blown out. What makes you so sure it's not HIM?
Re: (Score:1)
Re:What about "Import Grade" (Score:4, Informative)
Do you use SSH? A heck of a lot of US citizens do and trust it. It wasn't written in the US because of the crazy encryption restrictions the government has. The OpenBSD group runs it.
http://www.openssh.com/history.html
"for the ssh protocol in the 2.6 release, but we had to make sure that it was perfect. Therefore, we decided to immediately fork from the OSSH release, and pursue rapid development using the same process as the original OpenBSD security auditing process. The initial import was done on Sep 26, 1999, and, at the time of release two months later, many of the source code files were already at RCS revision 1.34... some as high as 1.66. Development went very fast indeed, since we had a deadline to meet.
The following team members participated:
Theo de Raadt (CANADA) started by removing non-portabilities which made the code harder to read -- the goal being simpler source code, so that security holes and other issues could be spotted easier.
Niels Provos (GERMANY but living in USA) quickly removed the remaining cryptographic and GPL'd components by doing road trips to Canada, so that we could end up with a completely freely reusable source code base.
Markus Friedl (GERMANY) jumped in and very quickly managed to replace the SSH 1.3 protocol code from the 1.2.12 release, with a SSH 1.5 protocol implementation compatible with the modern "ssh 1.2.27" series (this change was needed to operate with a lot of SSH-compatible Windows clients which lack support for SSH 1.3 protocol). His implementation is now used in OSSH. He added SSH 1.5 protocol support in such a way that SSH 1.3 protocol support remained operational. Later, he also added support for SSH 2 protocol and SFTP.
Bob Beck (CANADA) helped with Makefile magic to ensure that we could compile OpenSSL without patented algorithms. Because OpenBSD 2.6 was shipping before the RSA patent expiration date, we needed to ship our CD with libssl and libcrypto shared libraries which lacked RSA. At install time, the user was able to replace these libraries via FTP/HTTP over the Internet. Luckily this kind of hackery is no longer needed.
Aaron Campbell (CANADA) improved numerous documentation flaws and a few other code problems. It is mostly due to him that the manual pages are so complete.
Dug Song (USA) helped with some authentication issues in the KerberosIV case (his changes were carefully checked to ensure they stayed away from any cryptography, and only touched on authentication issues). "
Re: (Score:2)
What benefit do you think the US government gets from harming you?
Re: (Score:2)
Probably none.
But then, why are they doing it anyway?
Re: (Score:2)
For a variety of reasons including incompetence, collateral damage, organizational dysfunction, pandering to win elections, and prioritization of small short-term goals over significant long-term goals. But it's incredibly naive and misguided to fail to appreciate two things:
1) The United States has both statutory and institutional controls over law enforcement and national intelligence that are much stronger than many other country's.
2) Foreign governments do in fact use their foreign intelligence capabili
Re: (Score:3)
hmm... considering that the average US citizen hasn't any ties with the Chinese government, the answer is obvious.
Of course it's a different answer for US citizens with international political or business contacts or any kind of contact to China
I know the answer is slightly surprising, but having to ask that question alone should ring everyone's alarms, as one of these examples is known to be a anti-democratic regime violaiting human rights and suppressing their citizens.
As average person in a democratic, y
Re: (Score:2)
But would a US Citizen trust encryption from another country to not have a backdoor or other such weakness that might allow that country's government to crack it easily?
Export of crypto is limited. Inside the US you can use anything. IIRC the Supreme Court already ruled speaking encrypted is protected by the First Amendment.
Re: (Score:3)
Re: (Score:2, Informative)
Canada [libressl.org]
Germany [gnupg.org]
Re: (Score:1)
Back when export control was still an issue, the not-yet-greybeards would get their PGP here [pgpi.org], which is in Norway.
Re:What about "Import Grade" (Score:5, Informative)
http://openbsd.org/ [openbsd.org]
http://www.openiked.org/ [openiked.org]
http://www.libressl.org/ [libressl.org]
Re: (Score:2)
These days (since around 2001), open-source software is basically exempt from the US ITAR export rules (with some qualifications—if you're planning to export crypto software source yourself, you need to check out the rules). Back before that was true, every major Linux distro had sites in Europe to host the essential crypto software (e.g. nonus.debian.org).
So, I dunno about Windows or MacOS, but with Linux, the reason you haven't seen any download links is probably that you're too young!
Re: (Score:2)
So, I dunno about Windows or MacOS, but with Linux, the reason you haven't seen any download links is probably that you're too young!
I started compiling Linux source in 1997 in my early 30's I routinely downloaded from Australian FTP servers because a fast link existed between there and Silicon Valley for downloading on a 56K modem. Crypto software has never been an issue for me until now.
Re:What about "Import Grade" (Score:5, Informative)
Of course, they do protect — encryption is a weapon [theguardian.com] and you try to limit access to your best stuff [quora.com]. Yes, the enemies may still be able to get some of it, but your efforts make it harder for them.
Cryptography advances outside of the US made the point moot by early nineties, and the export-restrictions [wikipedia.org] were dropped. But they weren't "stupid" — except, maybe, for the very last year or two.
The article's emphasis is all wrong — the vulnerabilities are due to poor design of SSL2 [wikipedia.org] and the coding practices of OpenSSL [acm.org] developers leading to poor implementation of the rest. Neither of these problems is due to the government's export-restrictions.
Re: (Score:2)
Where are my mod points when I need them.
Although, there have been documented instances where the feds meddled in things, like Dual_EC_DRBG.... So lets not assume the governments hands are completely clean.. but in this case, yeah the feds had no involvement.
Re: (Score:2)
Cryptography advances outside of the US made the point moot by early nineties, and the export-restrictions were dropped. But they weren't "stupid" — except, maybe, for the very last year or two.
Yes, they were stupid. There were no significant cryptographic primitives in use in the US about which full details hadn't been published, or indeed, of which implementations weren't available worldwide. Many of the "export-grade" ciphers were the same ciphers used in the US, just with arbitrary restrictions on key length.
There was no point in time where encryption tools available to US corporations and citizens were significantly better than tools available outside of the US.
Re: (Score:2)
Of course, they do protect — encryption is a weapon [theguardian.com] and you try to limit access to your best stuff [quora.com]. Yes, the enemies may still be able to get some of it, but your efforts make it harder for them.
More relevant, encryption is a defense. And it's that aspect of it where limiting access to it is harmful.
All the US Gov't needs is some rope... (Score:2)
..so they can hoist their own petard themselves.
Seriously, US Gov't -- keep digging, you'll finish your grave soon 'nuff.
Re: (Score:2)
..so they can hoist their own petard themselves.
I thought that they needed a mortar and especially a mortar shell, to hoist on their own petard.
Re: (Score:2)
I've always thought of it, for some reason, as involving rope and a flagpole. o.O
Re: (Score:2)
Also. . . (Score:2)
"Government's Fault" is a bit of a reach (Score:5, Insightful)
Re: (Score:2)
Indeed. It's been known for quite a while that older SSLs were crap, even before DROWN. When the CVE hit, I checked the servers I'm responsible for, and discovered that I'd already disabled SSLv2 not long after I took the job. I'd simply forgotten having done so.
We're trying. (Score:2)
wrong (Score:2)
The major problem is neglect (Score:2)
Base libraries like these are often widely used but everybody assumes somebody else has done the code reviews and exploit testing. It took some major exploits like heartbleed to make people realize that OpenSSL was understaffed, full of cruft and really far from the ideal crypto library. Yes, in this case it was a downgrade exploit to an export cipher. That doesn't mean the US government is generally at fault for downgrade attacks, it's poor coding. That a library might have support for old yet known flawed
Export restrictions on crypto always seemed so sil (Score:2)
It's not like it's hard to export things over the Internet, even if it's "against the law", and it only has to be done once.
This sounds like a law put in place more for "the feels" than to actually accomplish anything.
Here are the best I could find (Score:2)
[ REDACTED by order of the NSA]
and my personal favorite:
Warrant canary (Score:2)
Perhaps companies/groups that write such software could implement a "warrant canary." See https://en.wikipedia.org/wiki/... [wikipedia.org]
Once you are served with a secret warrant, you are legally bound not to disclose that you have been served. They can however stop updating the "We have not been served" status on their website letting users/people know that they have been served.
If you work on an security project and haven't been served, please do this now. And blink twice if you can't say anything....
Re:Warrant canary (Score:4, Interesting)
Re: (Score:2)
I wonder if there's any case law on failing to prevent the existence of a secret warrant becoming known through intentional inaction was prosecuted. The cases might be analogous.
Re: (Score:1)
That would be an interesting case indeed because it would compel parties to engage in a form of speech against their will.
http://law2.umkc.edu/faculty/projects/ftrials/conlaw/compelledspeech.htm
Click here if you're in the USA or a terrorist (Score:2)
I remember those good old days and the choices you got to download software:
Click here if you're with the USA, or you want better encryption, or you're a terrorist, or you think this concept is retarded.
Click here if you're an idiot and outside the USA.
Why not (Score:1)
Re: (Score:2)
I'm ignoring the legal and moral issues and looking only at the technical ones.
If access was only for national security, that might work. But the problem is that law enforcement around the country wants access to this information any time any judge anywhere issues a warrant. That would mean the database of such passwords would be accessed by thousands of people around the country every day.
Some of those passwords would protect a twelve year old's text messages with their friends. Some of them would protect