It is well known that development of open-source cryptographic tools is very problematic within the United States: all open-source ssh-based software was specifically developed outside of the US of A due to the USA export restrictions.


Whilst located in the United States, what if I wanted to re-use some MIT-licensed ssh code, like from OpenSSH, Dropbear or PuTTY, and write some functionality on top of it, and publish results as open-source under a similar licence as that under which I've acquired the original code?

I am not a math person, so my ssh contributions will most likely consist of deep-level-integration parts only: for example, creating various kinds of ssh-based file transfer clients.

Am I opening the door for being potentially prosecuted in a criminal case for US export violations?

  • 8
    Consult a lawyer if you are worried about legal implications. Don't ever take our word for it. – Steve Dec 29 '12 at 22:38
  • 1
    Agreed - whilst we may be able to offer some ideas and advice, please don't ever consider it to be proper legal advice. Always consult a lawyer for matters like this. – Polynomial Dec 30 '12 at 0:22
  • @cnst I'm working with a lawyer on a similar (non ssh) project. I'd like to compare notes (or with anyone else who is interested) offline. Contact me at g mail with my name if interested --> – halfbit Dec 30 '12 at 21:41

Most strong-crypto export restrictions have been lifted, but not all. You can't sell to "rogue states" or terrorist organizations for example.

Wikipedia: Export of cryptography in the United States

As always, though, consult a lawyer, not the Internet, with respect to legal advice.

  • 1
    How can I ensure that I don't "sell" to "rogue states"? If the code is freely available on the internet, then any terrorist or "rogue state" could easily download and use it. – cnst Dec 30 '12 at 1:03
  • 1
    @cnst - ah, the joy of legal compliance. So simple and yet so absurd. Actually, supposedly the rule for open-source software is that you have to send out a notification when the software is published. – tylerl Dec 30 '12 at 3:08
  • Cuba is in the same category as "rogue states", right? – Martin Schröder Dec 30 '12 at 12:39

A trick often used by US based groups that want to make use of an encryption capability is to often a way of loading in this capability separately. Build your application in such a way that it is not distributed using the crypto source code, and provide additional instructions for how to get your preferred source code from the creator and build/link it into code you are providing.

This works as long as you are not modifying the libraries, but only building on top of them.

Mileage varies with development language and technical savy of users.

It's also nice in that it forces some level of abstraction - if you have only a limited suface area for the APIs that you don't want to export, it also means you have only a limited reliance on them, and could more easily upgrade or switch them should you later find something else you like better.


I think that as long as no actual cryptography code is re-published together with the new ssh-based tools, then such ssh-based tools can be written within the US.

I would hypothesise that it might limit the ability to actually implement deeper-level integration between existing ssh products and that for which ssh-integration is being sought: for example, doing an sftp client might end up being somewhat tricky, depending on how good the abstractions were done in the original code that was imported to be hacked on.

But, basically, publishing lone set of patches that do the integration between the existing ssh-based code and the filesystem clients, should, IMHO, be a safe bet to go. Just make sure that no original ssh implementations or any cryptographic functions are published together with such patches.

  • 1
    The lawyers at SourceForge use this sentence as checkbox for projects to toggle the USA censorship enforcement: "This project incorporates, accesses, calls upon or otherwise uses encryption software with a symmetric key length greater than 64 bits ("encryption"). This review does not include products that use encryption for authentication only." – Hendrik Brummermann Dec 30 '12 at 10:18

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.