This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
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.
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:
It's possible that the applet needs to be signed in order to allow this. [ December 05, 2008: Message edited by: Ulf Dittmer ]