Best JCE Provider?

[Anant K Agarwal]

Hello Ranchers,

Which Provider provides the best implementation for JCE. I am looking for Opensource.

Thanks.

[Richard Tookey]

Everything depends on what aspects of the JCE you require and by what criteria you define 'best' . The most simple to work with is the one provided by the JRE since it requires no additional jars; the most comprehensive that I am aware of is the Bouncy Castle implementation which is also open source; the fastest - who knows!

[Anant K Agarwal]

Thanks Richard for your reply. I basically need all the Industry standards algorithm implemented. Its up-to the user to choose what kind of encryption algorithm that needs to be used by the system. Hope it makes sense now. I am not sure about the JCE licensing requirements that is provided by default in JDK 6. I am going through a book on cryptography "O'Reilly Java Cryptography" and the author says that JCE can be used only in US, not sure if that still holds good today.

[Richard Tookey]

"O'Reilly Java Cryptography" is a bit dated now though I still recommend it for learning about the JCE. There are two aspects to JCE licensing. First you have the US government's armaments licence which dictate the limits on the strength of encryption and then you have the standard software licence.

I know that the US government have relaxed some aspects of their licence but I'm not sure by how much. To get full strength encryption you still do require the installation of the Unlimited Strength files and people in some countries are not allowed to download them. How this restriction can be policed escapes me ! If you use the JCE then the requirement to use the Unlimited Strength files applies even if you use a different provider.

As far as the software licence is concerned; check with the provider.

For the most part I have now dropped using the JCE because of the requirement to install the Unlimited Strength files. It is difficult enough making sure that my users have installed the required JRE without then having to get them to download and install the Unlimited Strength files (a non-trival task for many of my users). Whenever possible I now use the Bouncy Castle lightweight cryptography API which does not have the US government's restrictions or need the Unlimited Strength files.

I have no idea what product you are creating but I would counsel against allowing unrestricted choice of algorithms. A lack of understanding of cryptography by your users means it is far too easy for them to choose a bad set of algorithms and create a weak system. They will then likely as not blame you. In your position I would only allow the industry standards such as AES, RSA and DSA and make sure that a good block mode, IV selection where applicable, key strengths and key storage are enforced.

[Anant K Agarwal]

Thanks again Richard for such a detail post, really appreciate your time and effort.

The user using our system will have a choice to the algorithms that we will support. For example the algo's that you have mentioned (AES, RSA and DSA). We won't allow them to choose other weak algorithms. You can think it in terms of drop down values that they can choose from. This is the first part of the requirement.

Also some users may supply their own algorithm as jars and they can ask us to use it. Now since we will follow JCE they need to provide jars that are compatible to this architecture. Hope I am making sense. So as per your suggestion I will go with Bouncy Castle as a JCE default provider for our product and if users don't want to use that they can provide their own implementation of what-so-ever algorithm they wish to use.

So I am new to cryptography, where would I find industry level standard algorithm that are currently being used.
Thanks again for all your time and effort.

Just to add, our users need not install any software. Since our's is a Web application and we will be controlling the encryption and decryption process.

[Richard Tookey]

Anant K Agarwal wrote: So as per your suggestion I will go with Bouncy Castle as a JCE default provider

I don't think I have suggested Bouncy Castle as the JCE default! If you are going to allow only the standard algorithms then just stick with the SunJCE provider !

for our product and if users don't want to use that they can provide their own implementation of what-so-ever algorithm they wish to use.

Not a trivial task to create a provider. You might do better to create a provider of your own that has the ability in install plugins.

So I am new to cryptography, where would I find industry level standard algorithm that are currently being used.

You will have to research this yourself.

Just to add, our users need not install any software. Since our's is a Web application and we will be controlling the encryption and decryption process.

Ouch ! Think about key security before going any further! You need to be able to deny that you have access to the keys so that any breach of security cannot be attributed to your software. If you keep the keys on your system then no matter how you protect the keys on your system they have to be in the clear to be used on your system. If the user keeps the keys then he has to pass them to your system before they can be used and once again they have to be in the clear to be used.

You can get round this problem by using a tamper proof HSM where your customer's keys are passed to the HSM encrypted using the HSM's public key. But using an HSM you will have trouble adding a user's own algorithms ! Since you are creating a Web application you will need a bank of HSM modules and these ain't cheap!

Edit : The more I think about this project the less I like it. Even without the key security problem you have a BIG security problem in that the cleartext must exist in your server both before encryption and after decryption.

[Anant K Agarwal]

Thanks again Richard!

I am little skeptical about JCE licensing requirements, so will go ahead with Bouncy Castle (Sorry for suggest part of it).

Will read some more material and research on the Internet regarding the algorithms.
Thanks for all the info.