This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Security and the fly likes Bouncy Castle vs. Sun's JCE Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "Bouncy Castle vs. Sun Watch "Bouncy Castle vs. Sun New topic
Author

Bouncy Castle vs. Sun's JCE

James Dekker
Ranch Hand

Joined: Dec 09, 2006
Posts: 215
What's the difference between Bouncy Castle vs. Sun's JCE?

What are their advantages vs. disadvantages?

Thanks,

James
greg stark
Ranch Hand

Joined: Aug 10, 2006
Posts: 220
They work together. Sun JCE is has two layers, the crypto API layer and the provider layer. Typically, the programmer's only chance to interact with the provider layer is through the getInstance() methods that the crypto API classes provide. So, for example, if you want to encrypt some data with AES, you might get started by calling Cipher.getInstance("AES/CBC/NOPADDING"); Now all the installed providers are queried to see if any one implements this transform. You can add Bouncycastle to the list of these providers by having the Bouncycastle provider on your classpath and the line Unless you configure things differently, when multiple providers can implement the same algorithm, you get the implementation form the highest ranking provider which is going to be the Sun provider. If for some reason you want to use the implementation from a specific provider (perhaps because you know it is faster), you can specify the provider in two-arg version of getInstance(). So, for example, if I ask for I get the SunJCE provider AES; if I ask for I get the Bouncycastle provider AES; and if I ask for I get the Bouncycastle provider Twofish, because Sun's providers don't implement Twofish at all.

Bouncycastle also has a lightweight crypto API that doesn't interact with the JCE in any way. It is completely self contained and can be used instead of the JCE classes.


Nice to meet you.
James Dekker
Ranch Hand

Joined: Dec 09, 2006
Posts: 215
Thanks for the intuitive feedback, Greg!

I don't really understand all this security terminology (e.g. ciphers, AES/CBC/NOPADDING, TwoFish)...

Question(s):

(1) Which one is faster and more portable?

(2) Basically, which one is more effective if you are going to build a KeyGenerator component which will be included in an EAR / WAR bundle and deployed to multiple app servers (JBoss, WebSphere, etc)?

(3) I know that you can set the provider in Sun's JCE to specify IBM or Sun's JCE, for portability purposes. Is Bouncy Castle just an outside implementation of Sun JCE? It is more heavy duty?

Happy coding to you!

James
[ April 20, 2008: Message edited by: James Dekker ]
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41155
    
  45
(1) Which one is faster and more portable?

Can't speak about performance, but using BC is probably more portable, because it is the same on all JVMs. If you use the default JCE provider, you might get Sun's on a Sun JVM, IBM's on an IBM JVM, Apple's on an OS X JVM. Of course, these ciphers are standardized, so I don't know if any differences would be noticeable.

(2) Basically, which one is more effective if you are going to build a KeyGenerator component which will be included in an EAR / WAR bundle and deployed to multiple app servers (JBoss, WebSphere, etc)?

Not quite sure what you mean by "effective" - is this about the problem with product activation keys? Then I would assume it doesn't make much of a difference, but I haven't been following the details of that problem.

(3) I know that you can set the provider in Sun's JCE to specify IBM or Sun's JCE, for portability purposes. Is Bouncy Castle just an outside implementation of Sun JCE? It is more heavy duty?

I think JCE implements some algorithms Sun doesn't (and possibly vice-versa), and -as Pat pointed out in a different thread- it does so in a legally exportable, high-strength way. This last point is moot these days, as US export restrictions have been eased.


Ping & DNS - my free Android networking tools app
bill rom
Greenhorn

Joined: May 13, 2008
Posts: 1
Hi all,
I have some questions please on this topic,
I am trying to use some crypthographic algorithme specially AES.
When I use : Cipher.getInstance("AES/CBC/NOPADDING");
I have this error message :

Exception in thread "main" java.lang.SecurityException: Unsupported keysize or algorithm parameters
at javax.crypto.Cipher.init(DashoA6275)
at mac.main(mac.java:90)

Have you an idea about this please !!!
Thanks,
Bill
Nicholas Jordan
Ranch Hand

Joined: Sep 17, 2006
Posts: 1282
Originally posted by bill rom:
(...snip...)Exception in thread "main" java.lang.SecurityException: Unsupported keysize or algorithm parameters
at javax.crypto.Cipher.init(DashoA6275)
at mac.main(mac.java:90)(...snip...)


I am having the same issue, I got runs by reducing the keysize to 128

Is this a student project ( or independent study ) if there is actual value involved in any way, including your reputation, then not only keysize but a plethora of other issues must be examined with opportunity for direct attack.


"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4646
    
    5

Originally posted by James Dekker:

I don't really understand all this security terminology (e.g. ciphers, AES/CBC/NOPADDING, TwoFish)...


There are many many ciphers. To use a the java crypto API, you have to know which one you want to use. Perhaps you have seen 'ROT13" which was used to hide dirty jokes, it simply rotated each character 13 places down the alphabet.

AES is a cipher, so is DES as is Twofish.
Advanced Encipher Standard,
Data Encryption Standards,
and who knows what two fish stands for, perhaps lunch.




(1) Which one is faster and more portable?


Ciphers are in general designed to be machine portable. They operate on octets, which are unsigned bytes in C, but Java really doesn't have the exact data type.

If you consider the clear text or the cipher text as just an array of octets, then you don't have to worry about things like big endian, little endian, etc.

You should be able to properly implement say AES on an Intel x86 in Java, and decipher the data on a PDP-10 in Bliss.

How to do each side is an exercise left to the student.

Faster is another open question. in at least 99% of the use cases, the time that the crypto takes to do a function is invisible compared to the time to get the array of octets over the 'net, or from the disk.

AES with 128 bit keys is strong enough for serious work, if your needs are more serious, you won't be asking here on Java Ranch.

I am not sure what you are really looking for, if its just a product key, you should use a HMAC rather than a cipher
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bouncy Castle vs. Sun's JCE
 
Similar Threads
KeyGenerator using JCE
Bouncy Castle encryption examples and tutorials
"Gaps" in Sun's (Java 1.5) JCE vs. Bouncy Castle 1.41
Best 3rd Party Libraries for Secure Key Generation?
Encryption