Which aspects do I need to consider when designing and publishing software that must meet the US export restrictions for cryptographic software?

Wikipedia says that there are various categories which you can assign to cryptographic software. And the export destination (e.g. China, Russia) does play a major role as well. But I didn't really understand those restrictions and their effect on my work.

Can anybody explain that to me?

I'm asking because if you try to publish your application (e.g. on Apple's App Store or Android's Market) you have to assure that your application meets the US export restrictions. And there are lots of applications who offer secure information storage, e.g. for passwords.

Have they all notified the government and asked for a review? Of course, you cannot know if they did. But do they need to do this?

  • 1
    Your first prognosis became true. But regarding the second one: This is a question which is interesting for lots of programmers, isn't it? Many have published software which uses cryptographic algorithms. So somebody must know.
    – caw
    Dec 31 '11 at 0:49
  • Yes definitely, that doesn't mean anyone is certain enough of what you've done to give you definitive advice. See "go see lawyer" below!
    – Ben
    Dec 31 '11 at 11:16
  • You may check out the FIPS website for more details
    – Ubermensch
    Jan 4 '12 at 13:47
  • 1
    For something like this, I'd consult a lawyer. My career is in the defense industry, including at contractors who create products for domestic as well as foreign customers. There is not only a legal team, but specific export control specialists that review everything to make sure it's following the guidelines. There are a lot of little things to watch out for and relying on an answer from a software developer isn't wise since it's so easy to overlook something important.
    – Thomas Owens
    Jan 10 '12 at 11:44
  • 1
    Thank you, Thomas. I just thought it may be a clear case as there are sooo many application in Android Market (all must meet the guidelines) that use AES Encryption. Imagine, all the banking apps, the password storage apps etc ... And I don't sell my applications, I offer them for free. So asking a lawyer is expensive.
    – caw
    Jan 10 '12 at 17:28

If your code is open source, the restrictions are very light-weight: you cannot export your code to countries or entities that have been restricted and you must notify the government of the location where they can download source and object files. You must make some effort to prevent the code from being downloaded by Cuba, Iran, Libya, North Korea, Syria, and Sudan. You must ask all your users to not export to these nations.

You will be expected to prepare lists of all "packages" and "files" that contain the encryption primitives. (I recall that we were allowed to skip hashing primitives that were used only for authentication or integrity controls.)

If your code is not open source, you must file for exceptions on your own code. I expect you'll need to prepare similar lists of source / object files and which algorithms are implemented for what mechanisms. I further expect it'll require review before the license is granted.

While I believe all my information is correct as of 30 December 2011, I am not a lawyer and cannot provide you with legal advice. These are simply pointers to currently-available US government resources.

  • 1
    Thank you! This sounds really complex and onerous. Please see my edit in the question: Is your explanation even for this case or only for software which enables user to encode or decode information freely?
    – caw
    Dec 31 '11 at 0:48
  • It is my recollection that hashed passwords aren't one of the things they're interested in -- so if that's all your application does, you're almost certainly fine. I can't speak for what any other application authors do...
    – sarnold
    Dec 31 '11 at 0:53
  • Okay, thank you. So if we take an online banking application or a password safe as an example - they both encrypt data for safe storage: Is this fine or must it be reported and reviewed?
    – caw
    Dec 31 '11 at 11:57
  • If you're relying 100% on the host OS to provide the cryptography primitives, you don't have to do anything. :)
    – sarnold
    Dec 31 '11 at 23:27
  • 1
    FROM JAVA'S UNLIMITED STRENGTH JURISDICTION POLICY FILES: The JCE architecture allows flexible cryptographic strength to be configured via jurisdiction policy files. Due to the import restrictions of some countries, the jurisdiction policy files distributed with the Java SE 7 software have built-in restrictions on available cryptographic strength. The jurisdiction policy files in this download bundle (the bundle including this README file) contain no restrictions on cryptographic strengths. This is appropriate for most countries.
    – caw
    Jan 5 '12 at 1:36

Are you writing your own cryptographic routines or merely calling a 3rd party routine?

The reason I ask is because if for example on Windows you are using one of the Microsoft provided routines then you are not the one publishing or distributing the controlled software, in which case your software would not be under any restriction.

  • Thanks for the answer! If this is true, it would be great :) I will be using famous algorithms such as AES, SHA etc. So I will reuse other algorithms and call native functions. I will not publish my own cryptographic algorithm.
    – caw
    Dec 31 '11 at 3:32
  • Marco: That is definitely the way to go. What operating system are you targeting?
    – JonnyBoats
    Dec 31 '11 at 5:15
  • 3
    Marco: Code your program to simply use the best routine available on the customer's phone, check at run time. Beside how much product will you be selling in Cuba or North Korea?
    – JonnyBoats
    Jan 2 '12 at 6:08
  • 1
    If you use the Microsoft-provided routine crypto on Windows, then you aren't exporting the stuff because you aren't providing it. If it's already there, it's presumably OK to call it. Using standard implementations of standard algorithms is still providing the crypto, and you may well be exporting it. (Also, don't write your own security software for production purposes, unless you have experience in the field. There's too many things you can easily get wrong.) Jan 10 '12 at 14:47
  • 1
    I'm pretty sure that you still need to file all that crypto export stuff if you're merely using crypto APIs. Oct 21 '13 at 12:00

If this is just a question for interest's sake, then the other answers are great. If it pertains to something you are actually doing?

GO SEE A Lawyer. NOW.

Are you still waiting? Then I'll expand.

Go see a lawyer. Now. Don't wait, don't think. If you don't have one already, find one. Ask them to put you in touch with someone who handles business law as a job. Check his credentials, and if they look right, sit down with that person and offer them money for advice. Feel free to negotiate on terms.

If you don't trust me, and I'll admit I'm being very definite without much experience in this area, read this article, written in May 2010, by someone who's been successfully running a family business since '93.

If you are trying to run an Indie game business, you are, first and foremost, running a business. All local, state, and federal laws apply. You need a business license. Or licenses. Every business should have a lawyer and an accountant. I personally have done without having a dedicated lawyer on tap (an unwise course), but every business should have a skilled accountant.

What this means is that someone whose business comprises two people selling games where lizards in armour beat up goblins is aware he's taking a risk by not having access to his own personal lawyer at all times.

Are you a business? Don't know. If you're selling something, you could well be. Guess who would know? A Lawyer.

You don't have to pay for a very expensive lawyer for a long time, but at the very least you need to have someone available by appointment who you can run things by before doing stuff that may be legally dangerous, and who can explain to you what may be legally dangerous.

Because here's the thing. If you do it up front, then many things apply.

  1. You're less likely to screw up and attract the attention of the govt.
  2. You're more aware when you have screwed up, and what to do about it, including an existing contact you can call to help you.
  3. If you do screw up and attract the attention of the govt, you can explain that you tried to do everything right, and have the notes from the lawyer to prove it.

If you don't? Well, I recently discovered that if you are aware that you're not competent to handle something, and you don't seek advice, that legally means you deliberately chose to screw up. In money, that's fraud. In export sanctions, I think it's on the same scale as treason.

Regarding internet research: This blog post was written in Jan 17 2011. And the first thing it says in there? That this stuff changed recently. So it could change again. It could already have changed. Which means that if someone blindly follows this 3 years from now, they could end up having to spend some serious time explaining to besuited men that they're not a traitor, they're just daft enough to think that blog posts are legal documents.

Do me a favour for my own peace of mind. Go see a lawyer.

  • Thank you very much for this detailed answer. It's just that I thought it's a clear case and easy to decide. I wrote in the comment to the question (above) why I thought this.
    – caw
    Jan 10 '12 at 17:31
  • Yes, and you could probably consult Apple directly in this case to get their rules, if you're only going to publish through the App Store, and if your App isn't doing anything particularly novel with the encryption. To be honest, I'd imagine that when you submit, if it's non-compliant, they'll throw it back. They'll have their own safeguards to keep the App Store out of sanctioned countries. They also have their own legal team to deal with this stuff, and that counts as dealing with a lawyer.
    – deworde
    Jan 10 '12 at 22:57
  • 1
    The question I answered was the more general "Which aspects do I need to consider when designing and publishing software that must meet the US export restrictions for cryptographic software?" For the Android/iOS specific stuff, then the people to consult would be Apple and Google. Send them an e-mail laying out what you plan to do, and they'll probably have a procedure all laid out for you.
    – deworde
    Jan 10 '12 at 23:03
  • But if something does go wrong, I maintain it'd be wise to have a local lawyer aware of your existence and what you were doing. Just in case.
    – deworde
    Jan 10 '12 at 23:05
  • Thanks for your additional comments. I will keep your words in mind ;)
    – caw
    Jan 12 '12 at 0:46

A slightly different answer, but why write the encryption code in the USA? Even if you write the rest of the product in the USA, it makes a lot of sense to do the encryption parts elsewhere. You can still sell your product in the USA, but you import into the USA, rather than export from the USA.

As an aside, in the early PGP days, the export rules were sidestepped by printing a book containing the source code, and exporting the book.

  • 3
    This is a very bad idea. US Sanctions/Export regulations apply to any company registered in the US, and determine vendors as well as sales. Yes, with a very clever lawyer you might find examples of people scraping around them using crazy legal trickery, but DON'T. Big companies have to pay hundreds of millions of pounds if they screw this up. Small companies, everyone goes to jail, bankrupt or both.
    – deworde
    Jan 10 '12 at 9:45

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.