Hi,U.S. Export home page for encryption can be found at
I wonder how OpenSSL users are handling the export regulations. OpenSSL is made of libraries, therefore libssl needs to call libcrypto to perform cryptographic operations with SSL keys which have been derived in libssl. How should libcrypto know whether a 128-bit SSL key contains reconstructable bits like in RC4-40, or whether it is a full- strength RC4-128 key? There are more things to observe than just this one if you want to ensure that cryptographic capabilities are limited but this one is just used as one of the more interesting examples.
The basic question amounts to: Is there an exportable version of OpenSSL?
http://www.bxa.doc.gov/Encryption/Default.htm
Links from the above page will reference the actual regulations covering all manner of exports which can be found at
http://w3.access.gpo.gov/bis/ear/ear_data.html
And then the standard recommendation is to get qualified counsel before exporting, or I expect you can submit the BIS documentation and see if they will give you permission to export. But in any case you will likely want to review the BIS web pages and some of the regulations to get a feel for what is required. The following is merely my take and obviously BIS is the final authority.
From the Guidance link you will see a Source Code link and that link page will cover the TSU exception procedures that would be applied to OpenSSL.
You may also want to look at the ENC exception page at
http://www.bxa.doc.gov/Encryption/enc.htm
The basic useful classifications are:
Publicly available source code: if you post your source, e.g., on the web, whatever that source code may be, you can export it without restriction (except that you may not intentionally export to certain countries, such as Iraq). That is, if you provide a general download page, as most download pages are, then if someone from Iraq happens to download your publicly available code, you should be OK.
Key bit length restricted code: 512 bits for asymmetric and 56 bits for symmetric (or less in each case) software that is not open source. You should be able to export weak encryption (with likely specific download controls to avoid exports to the few noted countries).
All other routes require a fair amount of red tape, except where you restrict exports to only a few noted countries, England being one, an option that seems marginal.
But you will need to provide the proper notifications to BIS in either of the above cases.
The result is that you should be able to export OpenSSL-only code either source or compiled without restriction (TSU). The problems arise when you either make any modifications to the SSL code or link it statically or dynamically with your private code.
If your private code has encryption components, which is frequently hard to avoid, then the easy export for OpenSSL does not help you. Although I have not tried it, it seems as though software without encryption components that linked to OpenSSL might still obtain the easy export for OpenSSL if some care was taken, but that route is not made clear at the BIS pages.
I am currently statically linking to OpenSSL and hard coding the specific weak encryption options and exporting under the weak encryption option, and of course with proper BIS notification.
You can email or phone BIS and speak directly to someone at their federal offices.
http://www.bxa.doc.gov/Encryption/contacts.htm
Also, and this does not change any of the above legal requirements, it seems to be well known that given the easy access to strong encryption by anyone with only a moderate coding ability, a PC, and Internet access, that any person or government wanting to deploy unbreakable encryption methods can easily do so, making encryption export regulations of little practical use for their stated national defense purposes.
Regards,
Neil Nelson
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
