FREAK, Logjam, DROWN All a Result of Weaknesses Demanded By US Gov't (csoonline.com)

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

Comments

What about "Import Grade"

[Archangel Michael]

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"

[freeze128]

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?

Re:What about "Import Grade"

[__aaclcg7560]

I keep seeing this statement to import crypto from outside the US but I haven't seen any download links.

Re:What about "Import Grade"

[Bert64]

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:What about "Import Grade"

[Anonymous Coward]

Canada
Germany

Re:What about "Import Grade"

[Bugler412]

Because it's been shown that in many data streams that they collect ALL communications and store it for future fishing expeditions, not only the specific target of interest at that point in time. There's no guarantee of you, your company or your (whatever) not becoming a target of interest in the future if say, for instance, some fascist demagogue was elected to office, (strictly hypothetical of course lol)

Re:What about "Import Grade"

[mi]

stupid laws that do not protect anyone from anything

Of course, they do protect — encryption is a weapon and you try to limit access to your best stuff. 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 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 and the coding practices of OpenSSL developers leading to poor implementation of the rest. Neither of these problems is due to the government's export-restrictions.

Re:What about "Import Grade"

[Sperbels]

Haven't you been paying attention to the government's whole argument for weakening encryption? Because one out of every few million nobodies like you and me become radical bombers and do things like blow up sky scrapers/marathons/etc and they want to be able to track down all your friends, family, and associates after the event.

Re:What about "Import Grade"

[iggymanz]

http://openbsd.org/
http://www.openiked.org/
http://www.libressl.org/

Re:What about "Import Grade"

[Anonymous Coward]

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:What about "Import Grade"

[bickerdyke]

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, you should not even have to consider if your own government is spying on you!

"Government's Fault" is a bit of a reach

[xxxJonBoyxxx]

I remember the 1990's crypto wars. But we've also had plenty of time to refactor our code, create secure-by-default installations and disable insecure implementations. In fact, as an industry, we've done it before for SSL 2.0, MD5, SSL 3.0, RC4 and now SHA1.

wrong

[ole_timer]

not that I'm in favor of government intervention, but those were all implementation errors. anything designed and built by humans has them.

Re:Warrant canary

[Bugler412]

that works until the next precedent setting court case that determines that failing to update the warrant canary is a form of communication prohibited by the gag order due to the intent of the operator. Coming soon to a federal court near you I'm sure.