In what scenarios would I use non-default Java crypto providers?

Question

My application is a web (Hibernate, Spring) no mobile clients. I need to go for an AES algorithm with 256 key size to secure the financial sensitive data in back end table. I am new to cryptography.

Other than Java Cryptography Architecture there are other providers like Bouncy Castle. Considering only AES. In the Java Cryptography API I see the support. To address what nature of requirements should I consider other providers like Bouncy Castle or Jasypt? What is the limitation in standard Java Cryptography?

Answer 1

EJP makes a clear point when to use an external provider, but I'll expand the answer significantly here:

1. if the functionality that you are looking for is not supplied by JCE; this can be because the algorithm - which can be a combination of cipher, mode and padding - is not implemented (EJP);
2. related: if the a supported algorithm is not supporting your use case (non-named EC curves, for instance);
3. if the algorithm implementation does not have the right properties for you (e.g., speed);
4. if you want to use keys in hardware HSM, smart cards, TPM modules etc., these are normally accessed through the Sun PKCS#11 provider nowadays;
5. if you want to have specific support, for instance the IAIK providers have a compatibility list, and provide support for their implementations;
6. if you want to use the NSS library or another (partial) software PKCS#11 implementation (Sun PKCS#11 provider again);
7. if you require FIPS certification (e.g. Bouncy Castle is working on FIPS certification);
8. if the implemented algorithm does not supply a name or alias you require;

There are however a lot of reasons to use the providers of Oracle:

1. reasonably well programmed, implemented and tested, the software is well managed, making it easier to trust the implementation;
2. used by most people, meaning that looking for solutions is relatively easy;
3. speedy, it is often more speedy than - for instance - Bouncy Castle;
4. related: AES-NI support, AES-NI is supported by AES intrinsics, e.g. for use in AES/CBC, speeding up AES significantly;
5. compatibility, the algorithms provided by the JCE are well supported (note that there is a separate list of algorithms that need to be supported by Java SE implementations, so e.g. the IBM JDK may not support all algorithms provided by Oracle).

Note that - in general - it is unwise to explicitly specify a provider in the software itself (using the getInstance() factory methods, it is better to leave this to the system.

If you want to simply encrypt using AES/CBC in software without FIPS requirements then I would recommend to stick to the default / SunJCE provider. The Bouncy Castle provider is much slower for AES in byte code. If AES-NI is supported I would not be surprised if the SunJCE will be four times faster than Bouncy.

Answer 2

If the algorithm or key size you want isn't listed in Standard Names you need an external provider that does support it.