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 allowed 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

– All classes used are part of the Java Development Kit so they do not require any external downloads in order to run.
– You have a choice of providers to choose from. This comes in handy if you need to make sure the provider being used has certain credentials e.g. certifications

Disadvantages

– Different JDK’s can have different providers. You can run into errors if a certain provider is specified as the default but it unavailable in the running JDK. You should only specify the provider if you have control over the implementing system. In smaller JDK implementations that were for example made for Java Mobile and embedded environments there may be none or a lack of providers.
– Not every algorithm is specified. It is quite limited in this regard but covers the most popular ones.

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

– Defines more algorithms and cipher suites than the JCA implementation. For example it can read formats like PEM and ASN.
– Since Bouncy Castle was created in Australia it does not have the 128 bit secret key restriction

Disadvantages

– This will have to be either included in the project that needs it or downloaded and added by the user. Either way it takes up a little more space which might be in short supply for some businesses.

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