Is Bouncy Castle API Thread Safe ?

Question

Is Bouncy Castle API (http://bouncycastle.org/java.html) Thread Safe ? Especially,

org.bouncycastle.crypto.paddings.PaddedBufferedBlockCipher org.bouncycastle.crypto.paddings.PKCS7Padding org.bouncycastle.crypto.engines.AESFastEngine org.bouncycastle.crypto.modes.CBCBlockCipher

I am planning to write a singleton Spring bean for basic level cryptography support in my app. Since it is a web application, there are greater chances of multiple threads accessing this component at a time. So tread safety is essential here.

Please let me know if you have come across such situations using Bouncy Castle.

Thanks in advance.

Answer 1

It really does not matter if the API/Code is thread safe. CBC encryption in itself is not thread safe. Some terminology -

E(X) = Enctrypt message X
D(X) = Dectrypt X. (Note that D(E(X)) = X)
IV = Initialization vector. A random sequence to bootstrap the CBC algorithm
CBC = Cipher block chaining.

A really simple CBC implementation can look like: P1, P2, P3 = Plain text messages

1. Generate an IV, just random bits.
2. Calculate E( P1 xor IV) call this C1
3. Calculate E( P2 xor C1) call this C2
4. Calculate E( P3 xor C2) call this C3.

As you can see, the result of encrypting P1, P2 and P3 (in that order) is different from encrypting P2, P1 and P3 (in that order).

So, in a CBC implementation, order is important. Any algorithm where order is important can not, by definition, be thread safe.

You can make a Singleton factory that delivers encryption objects, but you cant trust them to be thread safe.

Answer 2

Yes, Tnilsson, your reasoning is right. I found the following post,

http://www.bouncycastle.org/devmailarchive/msg04715.html

from bouncy castle's mailing list. It's not completely thread safe (atleast AES engine).