I see this notice in the TextSecure README:

The U.S. Government Department of Commerce, Bureau of
Industry and Security (BIS), has classified this software
as Export Commodity Control Number (ECCN) 5D002.C.1, 
which includes information security software using or 
performing cryptographic functions with asymmetric 
algorithms. The form and manner of this distribution 
makes it eligible for export under the License Exception 
ENC Technology Software Unrestricted (TSU) exception (see
the BIS Export Administration Regulations, Section 
740.13) for both object code and source code.

Why does the US Govt feel this software is "eligible for export"? Does that mean it has a circumvention available?

TextSecure is just an example. More generally, on what basis do govts allow export of encryption software? If a govt allows some cryptography software to be exported, does it imply that it is not stong enough?

  • as far in know are cryptography software in the rules classified as weapons, since cryptography always a part of the warfare was. Maybe it's just "eligible for export" because the rule a old relic or something like that
    – Serverfrog
    Jul 2 '14 at 12:35
  • There are probably laws against software that is meant to break or circumvent security systems as the result of doing so could be a crime. Also: apache.org/dev/crypto.html#classify Jul 2 '14 at 13:14
  • Did you stumble upon cryptolaw.org already?
    – Darsstar
    Jul 2 '14 at 13:43

From this Apache link, ECCN 5D002 can be summarized as:

  • Software specially designed or modified for the development, production or use of any of the other software of this list, or software designed to certify other software on this list; or

  • Software using a "symmetric algorithm" employing a key length in excess of 56-bits; or

  • Software using an "asymmetric algorithm" where the security of the algorithm is based on: factorization of integers in excess of 512 bits (e.g., RSA), computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve).

  • Software designed or modified to perform cryptanalytic functions If the cryptographic functionality is limited to one of the above definitions, it should be classified as ECCN 5D002, and the remaining two steps should be taken (described below). If the release may contain cryptographic functionality beyond what is described above, please contact the ASF Vice President for Legal Affairs.

In a nuttshell, it appears to mean that if it is software that encrypts with keys above a certain strength, it gets classified as cryptographic software. But I don't speak lawyer, so~

  • Thanks for the details. My question is a little abstract. Why is the definition the way it is? And would it imply anything about the strength of cryptography when a govt allows its export?
    – HRJ
    Jul 2 '14 at 13:26
  • Regarding your edit: Ah, so the Apache link defines what cryptographic software is, but not why it is "eligible for export".
    – HRJ
    Jul 2 '14 at 13:28
  • Well if its asymmetric with less than 56-bit (an AES-55, if it existed), or RSA 511, then it appears that ECCN-5D002 would not deem it sufficiently strong enough to be considered as cryptographic software. Jul 2 '14 at 13:29
  • 1
    @HRJ If I had to guess, the DOC and BIS just need to classify the product as something so that they can say "it isn't a nuclear bomb, its security software" so that they can say its allowed to be shipped. Jul 2 '14 at 13:32

Crytographic software and hardware is considered munitions by the US Government as it could be used for keeping wartime secrets. As such, it falls under US Export control. This level of control has been loosened significantly in the last 15 years or so, but there is still a fair amount of laws about what is and isn't covered.

Three of the main grounds for export I know is if the key length is short enough, if it is going to be used for banking security or if it is going to be used to be a thorn in the side of regimes that the government doesn't like. (For example, exceptions are often granted for software being targeted at avoiding censors and promoting freedom in tightly controlled nations.)

BIS Export Administration Regulations, Section 740.13 is the relevant section of law related to this. Overall, I wouldn't be too worried about it meaning that it can be broken by the NSA. For shorter key-lengths, there is a good chance it may mean that it is easier for them to break, but for the exceptions for critical security things such as banking and public interest, they are allowing use of the same kind of levels of encryption as the government itself uses.

The question I always ask myself is, what do you think the odds are the government would encrypt their own top secret communications with algorithms that they know how to break?

  • 1
    And it seems like a remnant of the pre-internet era, when you could actually hope to stop the proliferation of software. You can't sell your software to Iran, but they can just get world class security software from github or bitbucket... Jul 2 '14 at 13:43
  • 2
    @AndrewHoffman - the export controls don't really have much in the way of effective teeth, but they do effectively control what US trained cryptographers can do and where they can work if they plan on coming back to the US or a country that extradites to the US. Much of the concern is not so much enemies of the US getting the software as it is learning to understand how and why the technology is implemented the way it is so that they could make their own derivative work. still probably not particularly effective, but since when does that stop the government? Jul 2 '14 at 13:44
  • 3
    In related law, before entering Atlanta GA, you must dismount your horse, announce that you are entering Atlanta, then enter Atlanta before remounting your horse. Jul 2 '14 at 13:49
  • 1
    @HRJ - that is why they have to get a license exception. The review looks at how the software can be used to make sure it fits the use case. You couldn't export code that was designed to work with military radios because it would fail to pass the export checks. You can export something for letting smartphones send encrypted text messages. If some enemy nation wants to have their soldiers sending secure text messages, they can grab the software and make use of it, but without someone familiar with the encryption, it will be slightly harder to re-purpose the algorithm for a secure radio. Jul 2 '14 at 14:02
  • 1
    The workflows and analysis/proving of their quality/strength/effectiveness is beyond me, but implementing them isn't so bad. You break them apart into bite sized algorithms and tie them together in a schedule algorithm that consumes the bite sized ones. In that way they are pretty plug&play, you don't really need to understand why they work, just what parts go where. Jul 2 '14 at 14:46

I've heard, that governments just restricts encryption key length, but not the certain algorithms. This achieved by, for instance, law, enforces companies reducing key length for 56(this depends on country)bits for symmetric keys, and 512(this depends too)bits for asymmetric keys.

Software companies, as far as I know, not follow weak key length and just hardcode sufficient part of key, so the restricted length is not violating and user can influence only on 56 and 512 bits of key respectively.


The entire text is wrong. ENC and TSU are two different Export Exceptions. The way it works for "publicly available encryption source code" is there is a section in the TSU exception that allows export providing that notification of the location of the source is sent to NSA and BIS using email.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.