Open source developers may not realize it but in certain circumstances their work is subject to export regulation. When open source developers create an account on SourceForge.net they are required to agree to SF’s terms and conditions. Checking that innocuous little box to “opt-in,” they are acknowledging that they are aware and pledge to comply with Section 740.13(e) of the Export Administration Regulations (”EAR”) 15 C.F.R. Parts 730-772.
There are only three facts that you need to know about the above:
- The fact that you have no idea what this is does not get you off the hook
- See number 1
- See number 2
The fact is the US government regulates the transfer of encryption technology to other countries. One of the big challenges for multi-source developers, who create products which mix open source with other types of software, is understanding whether there is encryption in their code. As software developers increasingly leverage open source and other components, it becomes more challenging for them to have intimate knowledge of what is in their code.
If it turns out you are using strong encryption, then you most likely are required to submit a notification or license application with the US Commerce Department. Strong encryption uses key lengths greater than 80 bits for symmetric algorithms, 1024 bits for asymmetric algorithms and 160 bits for elliptic curve. The requirements differ depending on the function of the product, the end user, the destination country, the encryption strength, and the intended use. If you are using weak encryption (defined in my October 13th blog, then you are OK. If you are between the limits of weak and strong, well then… make friends with a knowledgeable compliance professional.
Black Duck Software published an analysis that we performed looking at the encryption content in open source projects. We found that about 7% of open source projects contain encryption algorithms, however not all encryption is strictly controlled. We did find nearly 8,000 projects which could require a notification or license application to be filed before exporting. This includes some of the most popular open source projects.
Our message for multi-source developers is simply this: “Know Your Code.” If you want to learn more about complying with encryption export regulations, we have put together a guide to encryption export compliance for open source developers (and for developers using open source).
PS: Two more facts – two popular sites, SourceForge and Google Code, have language about export in their user T’s & C’s. See below:
SourceForge Terms of Use
You are aware that all postings of open source encryption code controlled under U.S. Export Control Classification Number (ECCN) 5D002 must be simultaneously reported by email to the U.S. government. You are responsible for submitting this email report to the U.S. government in accordance with procedures described in this document and Section 740.13(e) of the Export Administration Regulations (”EAR”) 15 C.F.R. Parts 730-772.
Google Code Additional Terms: By using Google Code (the “Service”), you agree to be bound by our Google Terms of Services located here.
5.2 You agree to use the Services only for purposes that are permitted by (a) the Terms and (b) any applicable law, regulation or generally accepted practices or guidelines in the relevant jurisdictions (including any laws regarding the export of data or software to and from the United States or other relevant countries).
(This blog is a repost of my 10-21-09 entry on blog.blackducksoftware.com)
hmm
hmm is right
Yes, as strange as it may sound, this can affect you even if you are a citizen of another country and/or living outside the US. According to the US Export Administration Regulations, if the site that hosts your code for downloading is physically located within the US, then you have to comply with US encryption export laws. These regulations focus on the destination countries, end-users and end-uses of code, not the routing of packets as a file crosses the Internet. As a user of open source, you can download freely; the EAR generally holds the exporter, not the importer, responsible for compliance.
About 40 countries participate in the Wassenaar Arrangement which has its own set of export controls.
hashes and authentication
Are one-way hashes outside the legal definition for 'encryption'? Are asymetrical encryption routines used specifically for authentication given any special consideration?
limited cryptography
Hash functions like MD5 and SHA-1 are rarely controlled as there is no key or other user variable. Other forms of “fixed” cryptography such as compression (Huffman, ZIP, JPEG, etc.) and encoding (Base64, Binhex, Radix-64, etc.) are similarly viewed.
You can self-classify (with no notification requirements) if you are using cryptography (any key length) for certain limited functions. Users should not be able to encrypt files, text or data other than for access control (password, PIN encryption) or authentication like digital signatures or customer identification numbers. Note, this exception does NOT cover secure communications such as SSL and SSH. Also, there are special restrictions on exports to country group E (Cuba, Iran, North Korea, Sudan, Syria).
If you fall under the rules for limited cryptographic functionality, then the correct Export Classification Control Number to reference in your record keeping is ECCN 5D992 (for software products).
limited cryptography
I cannot find a posted example of software implementing SHA1 that is not at a minimum classified 5D992. Do you have an example you can point me to of an item not classified for encryption implementing SHA1?
Algorithms
Do you feel that strong security research "cryptanalysis" is increasing the speed that an algorithm retires?
algorithm lifespan
I bet you are right. We have the simultaneous impact of Moore's law and computer science.