Slashdot Mirror

← Back to Stories (view on slashdot.org)

Legally Distributing OpenSSL Internationally?

Posted by Cliff on from the spreading-the-word dept.

Scott Silver asks: "I want to sell some software that uses SSL for communication with a web server. I would like to use openssl, in fact, any ssl implementation. What legal/contractual hoops do I have to jump through to release the product in the US and outside of the US. Am I restricted to using the RSA ciphers in the US? If not then I can use Blowfish or the like and avoid patent royalties. If not how much will this cost? What specific restrictions do I need to make for downloading the software?" We've touched on this a bit when we discussed distributing encryption a while back, but that conversation really didn't take off. Here's hoping more useful information comes out with a less generic subject.

3 of 7 comments (clear)

  1. Suggestion (OT, but Rob should read this) by Anonymous Coward · · Score: 2

    There needs to be a new mod to the Slash engine. Basically, when a story is posted to multiple "sections" of Slashdot (e.g. Ask Slashdot and Slashdot) there should be multiple sets of "next/prev story" links. One for each section.

    This would probably boost the popularity of Ask Slashdot, since when an Ask Slashdot story got onto the front page, there would be links *in a front-page slashdot story* (and we know how important those are) directly to the next/prev Ask Slashdot stories.

  2. Where do you live? by bluGill · · Score: 2

    Seems obvious, but if your live in europe and just want to export to the US, what I have to say will not apply. Therefore, assuming you live in the US:

    You can sell to anyone in the US, assuming you make a token effort to assure it will not be exported by them. That is you can place your product on the shelves of your local compUsa (if you can get them to stock it) with just a minor legal disclaimer.

    If you want to sell internationaly: forget it. It can be done, the company I work for has been exporting 128 bit IDEA for years (1994 at least), but we have a large export deparment dealing with this. We have to prove to the US goverment that the organization we are shiping to won't use it for anything bad. Foreign banks have a general US exception to encryption export laws (which is why we are able to ship strong encryption to them) but that only means the goverment cannot reject you outrigt for proposing to ship strong encryption to a bank.

    How many sales do you intend to get? You can hire encryption experts overseas, give them yoru source code (without encryption hooks) have them add the encryption and hooks, and then import that to the US and sell to the Us, while they sell to everyone else. This however is easier said then done. Sun attempted it, and failed to satisfiy the law for reasons I don't understand. If you have lots of money and good lawyers you can use this loophole.

  3. Clarification by Ray+Dassen · · Score: 2
    Am I restricted to using the RSA ciphers in the US?

    Unless you have very good reasons, avoid RSA. While it is quite efficient, it is encumbered by a patent in the US. Unencumbered alternatives, like Diffie-Hellman (patent has expired), exist.

    If not then I can use Blowfish or the like and avoid patent royalties.

    Apples and oranges. In general, there are two kinds of ciphers:

    • Public key algorithms, like RSA and Diffie-Hellman. These need no prior secure channel to exchange keys, but are highly computationally intensive.
    • Private/shared key algorithms, like Blowfish, Twofish, Rijndael, DES etc. These are computationally efficient, but require negotiating a key beforehand (via some sort of secure channel, e.g. meeting in person).

    Due to the nature of the algorithms, systems like SSL and SSH combine both types: a public key algorithm is used to securely exchange a session key (for a shared-key algorithm); as such a key is small, it's not too computationally intensive to do so. That session key is then used to encrypt the remainder of the conversation using a shared-key algorithm.

    So, for SSL communication without patent hassles, you need to choose an unencumbered public key algorithm (say Diffie-Hellman) and an unencumbered private key algorithm (like 3DES, Blowfish, Twofish, Rijndael, arcfour, RC5).