11–20 of 45 posts
Can someone explain the US laws of export control around cryptography in layman's term?
So if you wanted to offer it to anyone outside of USA, you were treated as if you were trying to deal in tanks or fighter jets.
Does this matter? We (not just IT people, everyone in the world) always lack the imagination of what could happen, and every time we're caught off guard by the creativity of malicious people. Sometimes a government is to blame, but eventually it's just us. Again, security is a process and a never-ending game of arms race. When you stop playing, they'll get the best of you. (Disclaimer: this is for the sake of argumen…
I’ve been reading Crypto by Steven Levy, it’s on exactly this topic, and I’m astounded by how actively the NSA discouraged commercial research, and how early on it happened: mid-1970s.
> We asked MIT whether we could incorporate Kerberos (and other encryption) into the X Window System. According to the advice at the time (and MIT’s lawyers were expert in export control, and later involved in PGP), if we had even incorporated strong crypto for authentication into our sources, this would have put the distribution under export control, and that that would have defeated X’s easy distribution. Fascinati…
Did they really have to include strong crypto? Most secure protocols negotiate a cipher suite. They just had to add the ability to do so, and maybe some placeholder algorithm using the maximum allowed strength at the time.
Earlier quoted context omitted.
Did they really have to include strong crypto? Most secure protocols negotiate a cipher suite. They just had to add the ability to do so, and maybe some placeholder algorithm using the maximum allowed strength at the time.
The flip side is: Just imagine if Kerberos 1.0 with 40-bit DES was baked into X11 or even IPv4. We'd still be fighting those downgrade attacks. Or maybe we'd be layering real encryption over the broken-but-unremovable encryption, with all the overhead that entails.
Can someone explain the US laws of export control around cryptography in layman's term?
Earlier quoted context omitted.
The flip side is: Just imagine if Kerberos 1.0 with 40-bit DES was baked into X11 or even IPv4. We'd still be fighting those downgrade attacks. Or maybe we'd be layering real encryption over the broken-but-unremovable encryption, with all the overhead that entails.
Why do you think that is true? Cipher suite selection and whitelisting is not a new thing--even if plaintext with CRC32 is in the mix--we deal with it successfully enough in TLS and SSH all the time.
Not quite. Downgrade attacks has been a huge problem for TLS.
> We asked MIT whether we could incorporate Kerberos (and other encryption) into the X Window System. According to the advice at the time (and MIT’s lawyers were expert in export control, and later involved in PGP), if we had even incorporated strong crypto for authentication into our sources, this would have put the distribution under export control, and that that would have defeated X’s easy distribution. Fascinati…
Did they really have to include strong crypto? Most secure protocols negotiate a cipher suite. They just had to add the ability to do so, and maybe some placeholder algorithm using the maximum allowed strength at the time.
Related to this, you should definitely watch Moxie Marlinspike's (lead dev of Signal) talk where he tells about his discussion with Kipp Hickman, a developer of SSL: https://www.youtube.com/watch?v=UawS3_iuHoA#t=13m52s (until 16:33)
"Often hear that the reason today’s Internet is not more secure is that the early designers failed to imagine that security could ever matter." Related to this, you should definitely watch Moxie Marlinspike's (lead dev of Signal) talk where he tells about his discussion with Kipp Hickman, a developer of SSL: https://www.youtube.com/watch?v=UawS3_iuHoA#t=13m52s (until 16:33)
"The choice for all of us working on that software was stark: we could either distribute the product of our work, or enter a legal morass, and getting it wrong could end up in court" Is this not simply an economically expedient choice? To put the security and privacy of users below that of product distribution? How is this choice really different than any tradeoff a software company today makes about security?
There's a world of difference between choosing not to implement security features to allow faster shipping; and keeping security features out because with them you are not allowed to ship.
The first is garden-variety negligence. The second is politically mandated malfeasance.