Slashdot Mirror
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.'
Canada
Germany
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)
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.
In Soviet Washington the swamp drains you.
http://openbsd.org/
http://www.openiked.org/
http://www.libressl.org/
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). "