aspose file tools*
The moose likes Security and the fly likes Shipping unlimited encryption jars with Swing application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Shipping unlimited encryption jars with Swing application" Watch "Shipping unlimited encryption jars with Swing application" New topic
Author

Shipping unlimited encryption jars with Swing application

Robert Taylor
Greenhorn

Joined: Oct 04, 2009
Posts: 3
Greetings,

I have a Swing application which uses JCE and requires the unlimited version of US_export_policy.jar and local_policy.jar files.

I want to allow others to download and use this application.
The question is, how do I deal with the legal issues surrounding the use of the unlimited version of the
US_export_policy.jar and local_policy.jar files and still make the installation process as painless as possible?
How do other's deal with this issue? Can I simply include these files with my distribution bundle?
If so, do I become liable if someone from an unauthorized country downloads my application?

Thanks.

/robert

greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
Would you trust legal advice you got on a Java programming forum?


Nice to meet you.
Robert Taylor
Greenhorn

Joined: Oct 04, 2009
Posts: 3
greg stark wrote:Would you trust legal advice you got on a Java programming forum?

Hmmmm. i wasn't necessarily looking for legal advise per se...
I basically wanted to know how other Java software vendors dealt with this issue.





Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42612
    
  65
From the documentation: "Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited to, the denied persons and specially designated nationals lists is strictly prohibited." and "You are advised to consult your export/import control counsel or attorney to determine the exact requirements."

But even if the unlimited policy file is shipped with the application, it still needs to be copied to ${java.home}/lib/security/, and then the JVM restarted. I can't tell from the description whether that would be OK in your scenario.

An alternative approach would be to use the BouncyCastly library through its native API (as opposed to using it via JCE) - it doesn't have this limitation.


Ping & DNS - my free Android networking tools app
Robert Taylor
Greenhorn

Joined: Oct 04, 2009
Posts: 3
Ulf Dittmer wrote:From the documentation: "Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited to, the denied persons and specially designated nationals lists is strictly prohibited." and "You are advised to consult your export/import control counsel or attorney to determine the exact requirements."

But even if the unlimited policy file is shipped with the application, it still needs to be copied to ${java.home}/lib/security/, and then the JVM restarted. I can't tell from the description whether that would be OK in your scenario.

An alternative approach would be to use the BouncyCastly library through its native API (as opposed to using it via JCE) - it doesn't have this limitation.


Ulf, thanks for responding.
I've browsed the the Bouncy Castle docs and in more than one place they state that I must use the unlimited encryption jars in order to encrypt beyond 128.

http://www.bouncycastle.org/specifications.html#install
"Note: with JDK 1.4 and later you will need to have installed the unrestricted policy files to take full advantage of the provider. If you do not install the policy files you are likely to get something like the following:

java.lang.SecurityException: Unsupported keysize or algorithm parameters
at javax.crypto.Cipher.init(DashoA6275)"


http://www.bouncycastle.org/documentation.html
" If you are using JDK 1.4, or later, you must use the signed jar for the provider and you must download the unrestricted policy files for the Sun JCE if you want the provider to work properly. The policy files can be found at the same place as the JDK download. Further information on this can be found in the Sun documentation on the JCE. If you have not installed the policy files you will see something like:

java.lang.SecurityException: Unsupported keysize or algorithm parameters
at javax.crypto.Cipher.init(DashoA6275)"


Can you point me to the docs which explain how to use BouncyCastle library without JCE?


Thank you.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42612
    
  65
Can you point me to the docs which explain how to use BouncyCastle library without JCE?

The best bet seems to be the sample code that ships with the library; see #2 in http://www.bouncycastle.org/wiki/display/JA1/Frequently+Asked+Questions. I've never used the native API, so can't help with that.
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
Ulf is correct, but it helps to understand a little bit about the bouncycastle (BC) library. The BC library consists of two basic components, a fairly complete lightweight crypto library and a glue layer that allows the library to be used through the Sun JCE. You can use the lightweight crypto library classes directly if you want, or you can use some of the crypto functionality through the JCE. For example, to use the bouncycastle SHA1 message digest implementation, you can do MessageDigest md = MesssageDigest.getInstance("SHA1", "BC") to go through the JCE, or SHA1Digest md = new SHA1Digest() to use it directly. If you go through the JCE, the JCE will enforce the cryptography restrictions. If you use the bouncycastle classes directly, there is no enforcement of any restrictions.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

This is a radically difficult topic.

I'll make the assumption that the OP is interested in exporting code written in the US overseas. Mostly because few other countries have ITAR rules. And even in the US, if you import strong crytpo, you have no issues, the ITAR is all about exporting software. er, well its really about exporting arms and weapons, and strong crypto has been considered a military item for decades if not centuries.

The design of the JCE is to let you write code that uses crypto consistently without needing to worry about the ITAR. You can just plug in a proper JCE compliant library and all the code works as expected. You can let your customers get a JCE compliant jar file and use it, and then you don't have to worry about the issues.

The ITAR laws are a lot easier to deal with these days, they were very difficult back when I was writing crypto code for CyberCash in the 90s. But even then, it is possible to get approval to export strong code, we did it.

The beauty of the Bouncy Castle solution is that they are not US based, and so US ITAR rules do not have any impact on them. It is fully legal to import any crypto code, so you can just pay the license fee and use it to develop.

After that, the real answer is that you need to talk to legal council. Its just too complex, and dangerous both to your pocketbook and to jail time, if you get it wrong. Its simply not worth the risk. Be sure to find a lawyer who is conversant in these issues. You don't want to pay the lawyer to learn all of the complexities, as they are going to charge you a lot of hours if they need to get up to speed.

One other thing, while officially the ITAR export approval is from the US Commerce department, and they are who you talk to about getting forms, approvals, etc. in reality, they are a proxy for NSA, who does all the real decision and analysis on this stuff. The Commerce folks will not admit this, but if you need to have a meeting, its going to be at Fort Meade rather than the Commerce building downtown.



 
 
subject: Shipping unlimited encryption jars with Swing application