JCE policy, applet

[Ruben Silva]

Hello,

I work in a european security related company and we are developing an applet that provides the user with a way to encrypt files. Well, as you may now, JCE policy does not permit to encrypt stuff with a 1024 key by default.

To bypass that limitation we need to overwrite some jars in our JRE/lib/security. Since an applet is a client side application when the user tries to encrypt the file with a x509 public key, fails. Installing the libs in the client JRE solve the problem. However the applet is meant to be used by a large audience and can be problematic to make all kinds of users to understand what they have to do in order to make the application work.

So, after some googling I find this post javaranch topic.

Someone has crash into this already but no solution for a more transparent way to bypass encryption policy issue.

Glad for your attention and if you have the answer be nice and share it with me!

Ruben Silva

[Ulf Dittmer]

Welcome to JavaRanch.

I don't think it's JCE that doesn't permit strong crypto - it's Sun's default implementation of it (or provider, as JCE calls it). The BouncyCastle provider mentioned in that other thread does not have this limitation. Of course, it, too, must be installed, but this can be done at runtime without the need to copy any files. This will do the trick:

java.security.Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());

It's possible that the applet needs to be signed in order to allow this.
[ December 05, 2008: Message edited by: Ulf Dittmer ]

[greg stark]

Well, as you may now, JCE policy does not permit to encrypt stuff with a 1024 key by default.

I don't believe this is true for Java 5 and later.