>Encryption export restrictions are an absolute joke.
I don't think you give BIS & NSA the credit they deserve. Experto crede. The restrictions may serve a useful purpose and if you can't see it, that doesn't mean they are the ones missing the point.
Having myself had to pass the export control for one of my apps, and so having the opportunity to pour over the these regulations in great detail, I came to conclusion that the actual purpose of the crypto export regulation is not to control export of the technology. That sort of restrictions is impossible to implement, as you noted, and it's also quite unnecessary.
The actual purpose of the law is to prevent export of expertise. Implementing a crypto system that would be secure end-to-end is pretty much impossible without being an expert, and even then it's exceptionally hard. The best chances belong to a team of experts with a track record of fruitful collaboration and rich history in a particular area. Unlike bits and pieces of code, cohesive teams of experts are relatively easy to keep track of.
The way this control regime works, is that the entirety of the regulation revolves around two questions: 1) Are you supplying a turn-key end-to-end system to the client? 2) Are you supplying services to setup a complete, tailored system for the client? If the answer is "yes" to either question, that raises the red flag for the BIS/NSA, and they want to see what's going on there. Otherwise it's just a minor bureaucratic hoop to jump through. You are certainly welcome to export bunch of crypto code, and they even have a special open-source exception to the paperwork requirements.
So, you may disagree with the goals of this regulation, but it's certainly not a joke you make it out to be.
> 1) Are you supplying a turn-key end-to-end system to the client?
> So, you may disagree with the goals of this regulation, but it's certainly not a joke you make it out to be.
It remains a joke, when you consider how much really good open source software implementations are in the wild already. Think about the crypto in Debian and OpenBSD, including GPG, LUKS, openvpn, OTR, Open/LibreSSL with their support in Apache, nginx, etc. Even for Android, the best end-to-end encryption software (security-wise, not interface-wise) is open source. Let's face it, we have won this crypto "war" long ago. (This is not to say, we don't have other problems to deal with, regarding the immense power the NSA, etc have.)
And even all sufficiently secure software was closed source, as long as it is reasonably widespread, it will be easy to pirate the software instead of importing it from the US.
> 2) Are you supplying services to setup a complete, tailored system for the client?
What kind of systems do you have in mind? Afaik, the case referred to in the article does not fall into this category.
These are all components, not systems. A system would be something akin to a full-bank installation with all the computers, cabling, routers, crypto protocols, key generation/escrow/rotation/destruction, fall-back procedures, firewalls, hotglued USB ports, etc.
You can use those components to build a system like this, but you have to be an expert in it. This is why component export is restricted - all they want is to look into your design to see if you are an expert capable enough to design and implement a secure system. What happens if they pick interest in you is beyond my experience. I know, it speaks poorly of my crypto skills, huh?.. :) I imagine they would start looking into identity of the client(s), and see if they are connected to embargoed entities. Or something...
Fair point. I didn't recognize you had such a high level view of "system". But this raises the question whether one can really call these laws "cryptography export restrictions". Because, sure, cryptography is involved, yet the restrictions only apply to (/ are meaningful in regard of) the procedures involved in secure IT systems in general. I'd argue that this expertise is somewhat independent of cryptography, as you can swap the cryptography implementations with any other and the procedures would stay the same.
Even better, leave the cryptography out of the package entirely and just include an "apt-get install" line or a list of open source projects you have to install. Instructions for "cabling, routers, crypto protocols, key generation/escrow/rotation/destruction, fall-back procedures, firewalls, hotglued USB ports, etc." aren't cryptography in themselves, are they?
Fist, it adds more moving parts, making the system more likely to contain a hole, which might be just enough for NSA. Second, consider that typical buyer is a beauracracy, and they are are either buying a crypto system, or the are not buying it. The upgrade might be trivial for you, but a beauracrat has no way of knowing that, so he has to play by the rules.
I think they key to scale of the word system is however big it needs to be to establish actual security. You can have perfectly good crypto, but if you're relying on certificate authorities you may be safe from street hackers, but as far as NSA is concerned its wide open.
It's just reading tea leaves, of course. I imagine that NSA is not enjoying reading thousands of applications from iOS app devs like me, so if they keep doing it they must be getting something for their effort.
BTW, other countries can and do start to apply the same rules against US companies.
China started to have a lot more rules and regulations regarding to the importation of products with any kind of crypto.
They are becoming bigger IT/Mobile product market than US.
I can see in 2-3 years - as soon as the Chinese home grow Mobile SOC are mature, they will start to require Intel/QComm/Apple to disclose everything they do in the Chip/Software level relate to crypto before any of the next gen product are allowed to be sold in Chinese market.
The choice for AAPL/QComm/Intel will be do what the Chinese government wanted or loss access to 30-50% of customers on principle - like Google did a few years ago.
It's not illegal to export the system, you just have to get BIS/NSA permission to do that.
I see a few possible explanations on why they allowed it - 1) NSA was satisfied with their intercept capability (likely around key generation / exchange being based on cellular network/SMS) 2) they decided that the technology was a commodity and it's best to have Apple dominate it (where they can still attack the data center or use legal means) rather than cede it to a foreign power.
Whilst the ability to implement secure systems is certainly not commonplace, the United States doesn't have a monopoly on encryption and security expertise.
I don't think you give BIS & NSA the credit they deserve. Experto crede. The restrictions may serve a useful purpose and if you can't see it, that doesn't mean they are the ones missing the point.
Having myself had to pass the export control for one of my apps, and so having the opportunity to pour over the these regulations in great detail, I came to conclusion that the actual purpose of the crypto export regulation is not to control export of the technology. That sort of restrictions is impossible to implement, as you noted, and it's also quite unnecessary.
The actual purpose of the law is to prevent export of expertise. Implementing a crypto system that would be secure end-to-end is pretty much impossible without being an expert, and even then it's exceptionally hard. The best chances belong to a team of experts with a track record of fruitful collaboration and rich history in a particular area. Unlike bits and pieces of code, cohesive teams of experts are relatively easy to keep track of.
The way this control regime works, is that the entirety of the regulation revolves around two questions: 1) Are you supplying a turn-key end-to-end system to the client? 2) Are you supplying services to setup a complete, tailored system for the client? If the answer is "yes" to either question, that raises the red flag for the BIS/NSA, and they want to see what's going on there. Otherwise it's just a minor bureaucratic hoop to jump through. You are certainly welcome to export bunch of crypto code, and they even have a special open-source exception to the paperwork requirements.
So, you may disagree with the goals of this regulation, but it's certainly not a joke you make it out to be.