Can I develop SSH-based tools within United States?

Question

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.

http://www.employees.org/~satch/ssh/faq/ssh-faq-1.html#ss1.10.2

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.