Site iconJava PDF Blog

Which security implementation should I use: Bouncy Castle or JCA?

Over the past few weeks at IDRsolutions we have been creating methods that will decrypt an encrypted PDF using Java’s Cryptography Architecture (JCA). Previously we only 1024px-Padlock.svgallowed decryption if the Bouncy Castle jar had been included in the classpath. We wanted to remove this dependency so that the decryption code would still function correctly. BUT we also wanted to keep the Bouncy Castle code in there. This is so that if customers preferred to use the Bouncy Castle implementation/provider then they still could.

You may be asking why did you need to change the functionality if it was working or why did you keep Bouncy Castle instead of replacing it. The reason being that both implementations have their advantages and disadvantages and we thought having both would allow customers to choose their preferred option.

So before we go any further I should probably give a quick explanation about what Bouncy Castle and the JCA are.

What is the Java Cryptography Architecture?

The JCA is part of the Java Development Kit (JDK) and supplies functionality that allows you to perform cryptographic operations. The architecture aims for implementation Independence and interoperability and algorithm independence and extensibility.

It is made up of two key components that try to achieve these aims:

1) Provider Architecture – This allows you to specify a provider that will carry out the functionality for you. The sun JRE usually has some default providers and each one carries out their methodologies slightly differently. It also allows for the easy addition of new Providers, like for instance Bouncy Castle.

2) API’s for the engine classes – These engine classes are the base implementations of the different algorithms and the providers (if they support the functionality) override these classes. These define the minimum needs for components including: ciphers, signatures, messageDigests, keyFactories, etc.

What is Bouncy Castle?

This is a jar comprised of lightweight cryptography APIs that allow you to perform activities such as certificate generation and decryption. Originally it was created by two colleagues who did not want to have to reinvent the cryptographic wheel every time they changed to a new server side JavaSE job. They started development of this library and created a not-for-profit association in 2013 called the ‘The Legion of the Bouncy Castle Inc’ in Australia.

The jar is used along with the JCA as essentially Bouncy Castle is a provider and therefore has to interact the the JCA’s providers architecture. However it uses its own classes to implement the cryptographic functionality instead of overwriting the engine classes.

JCA: Advantages and Disadvantages

Advantages

Disadvantages

There is also one other key point to note about the JCA and that is by default it conforms to the American restrictions on the export of cryptographic software. This means that secret keys have to be 128 bits or shorter so that they are not too difficult to break if the need arose. In order to use larger keys outside of America you need to replace the security policy files in every JDK with the Unlimited Strength Policy files.

Bouncy Castle: Advantages and Disadvantages

Advantages

Disadvantages

 

And there you have it: an explanation, advantages and disadvantages of Bouncy Castle and the JCA.