Bouncy Castle as provider v/s Bouncy Castle API

Question

I have a case where I need to encrypt some files using OpenPGP. I am using Bouncy Castle to do so.

As I understand it Bouncy Castle encryption can be used in java in two ways:

I add Bouncy Castle as a provider and continue to use the standard Java libraries.
I use the classes specified in the Bouncy Castle library directly.

I wanted to know the pros and cons of both the ways and which method is recommended.

Also if I am using the second approach then why do I still have to add Bouncy Castle as a security provider. If I do not do so then I get a "No Such Provider" exception when I execute the following line:

PGPEncryptedDataGenerator encGen =
            new PGPEncryptedDataGenerator(
            new JcePGPDataEncryptorBuilder(PGPEncryptedData.CAST5).setWithIntegrityPacket(withIntegrityCheck).setSecureRandom(
            new SecureRandom())
            .setProvider("BC"));

Maarten Bodewes Maarten Bodewes · Accepted Answer · 2016-05-16T13:28:04

As I understand it Bouncy Castle encryption can be used in java in two ways:

I add Bouncy Castle as a provider and continue to use the standard Java libraries.

I use the classes specified in the Bouncy Castle library directly.

I wanted to know the pros and cons of both the ways and which method is recommended.

The Java JCA is a better designed and certainly better documented API. It has better defined exception handling, more up to date parameter handling (ByteBuffer).

Furthermore, through the use of the provider abstraction, it can be enhanced not just with software based providers such as Bouncy Castle, but also with platform functionality and hardware providers. So if you program against the JCA you'll be rewarded with a more flexible runtime.

On the other hand the lightweight crypto API is a relatively low level API that provides a lot more functionality in a relatively well structured fashion. If you use it you're basically choosing Bouncy Castle as your sole provider of functionality. Bouncy Castle contains specific implementations in Java code only, which means that you won't get (much) hardware support.

Bouncy Castle's lightweight API doesn't have jurisdictional restrictions (such as 128 bit AES keys). So you can use it for your own protocol if you want to work around those restrictions (don't get me started on the reason why these restrictions are there in the first place if you can download an equivalent library without issue).

Also if I am using the second approach then why do I still have to add Bouncy Castle as a security provider. If I do not do so then I get a "No Such Provider" exception (...) ?

The Bouncy Castle PGP functionality is actually build upon the JCA; it's that simple. If it wasn't you could not use Java keys or other (platform or hardware) cryptographic functionality.

A lot of other software components also assume the JCA to be used. You cannot simply plug the lightweight API into an existing protocol implementation.

Bouncy Castle as provider v/s Bouncy Castle API

1 Answers