3 ms·
> 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
by Perseids 12y ago
> 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.
- DenisM 12y agoThese 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...
- Perseids 12y agoFair 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?
- DenisM 12y agoFist, 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.