• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

AES256, cryptoPerms and Unlimited Cryptography

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We are trying to use AES256 encryption in our application. By default the JRE does not support this level of cryptography. To get this level of cryptography you have to deploy two "unlimited" additional policy files to your jre/lib/security folder. These files can be downloaded from SUN. This works, but deploying these files to the customer's jre/lib/security is really problematic for us.

There is another way to do this, according to the "Java � Cryptography Architecture(JCA) Reference Guide for JavaTM Platform Standard Edition 6". It describes a process by which we bundle a file called cryptoPerms into our signed jar files. The JRE will recognize our application as "excempt" from cryptography restrctions according to the cryptoPerms files bundled with our jar. We do not require an exception mechanism, which means we should be able to use the SunJCE prodider. We followed the instructions listed in the JCA reference guide, but we continue to receive "Illegal Key Size" exceptions when using AES256.

-Has anyone used a cryptoPerms file successfully?
-Are there any special rules or procedures (beyond what is in the JCA Reference Guide) we need to follow to make the JRE honor our cryptoPerms file?
-Is it possible to use the SunJCE provider in this manner, seeing as we do not require the Exception Mechanism?

I have found very little information on the web concerning this issue.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to JavaRanch.

I don't know the answer to any of your questions, but if you cannot resolve them, have a look at the Bouncy Castle JCE provider. It supports AES-256 out of the box.
 
Rancher
Posts: 4804
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry I can't help you with the specifics either. AES128 is accepted for sensitive data protection by NIS&T (really NSA) and encryption has always been controlled as a weapon. So I'm not surprized that AES256 is not a out of the box solution.

And I agree that having consumers diddle with their JRE installation is a non-starter, you are lucky if you can get them to install the JRE.

The legal issues are about exporting strong crypto from the US. Bouncy Castle is outside the US, and there are no restrictions about importing strong crypto.

Hey, I'm not one of the bureaucrats who wrote up these rules.
 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I worked this until I got about to where you are. I ended up writing a KeySpec that forced a bunch of issues I had scattered all over into one place. One of those things was to go to a 128 bit key because it would run ~ and thus I could get on with building other areas of my program.

I invested in two very recent, very good quality crypto books by First Class Tier publishers and found enough math to keep a B.S.C.S. busy well beyond all Postgrad work and all the way through a five year internship. Nowhere did I find - except for Jason Weiss' book - a let's get to it, this is how you do it book.

Unless you can demonstrate a clear and present need such as banking or something, I suggest getting it running with 128-bit and make that a parallel development goal to get 256-bit running.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have the same issue. Did you find a way to use the CryptoPerms file ?
What code signing certificate issuer do you use ?

Thanks a lot
Tricote
 
Ranch Hand
Posts: 290
Oracle Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had the same issue but for RSA. Luckily JDK 1.6 supports 2048 key length by default.
Aryan
 
tri cot
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the problem is that I use BouncyCastle. They say on the Official webSite that you must install the unlimited policy files :

Note: to make full use of the provider you must install the unlimited policy files in the JVM you are using - these can be downloaded from http://java.sun.com. Be careful if you are using Windows as the JDK install will normally install a JRE and a JDK in two seperate places - generally both of these will need to have the policy files installed in it.



To be a bit more precise :
My JAR file is signed, and I use the "CMSEnvelopedDataGenerator.RC2_CBC" algorithm of BouncyCastle with a key size of 128bits.

If i don't replace the 2 policy files in my JVM (1.6), I get the "java.security.InvalidKeyException: Illegal key size" Exception... even if i reduce the key size to 64bits.

I would like to include a "cryptoPerms" file in my JAR Applet, but I don't undestand how to use it. Does the cryptoPerms file need to be signed ? Does the code-signing certificate used to sign the JAR file has special requirement ?

Thanks
Tricote
 
Ranch Hand
Posts: 220
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#ExemptApps

Note however that bouncycastle consists of two libraries, the lightweight crypto library and the JCE provider interface library. The keysize restrictions are enforced by the JCE layer, but you don't need to use this layer. If you just use the lightweight crypto API directly you don't have any restrictions, no matter what policy files are or are not installed.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have placed the unlimited strenght jars in the jre/lib/security folder. but still iam not able to use AES 256. Iam getting the error as : java.security.InvalidKeyException: Illegal key size or default parameters

Can anyone help me out
 
We're all out of roofs. But we still have tiny ads:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic