"java.lang.SecurityException: Unsupported keysize or algorithm parameters"or
"java.security.InvalidKeyException: Illegal key size"when I try using the Bouncy Castle Provider?
If you see this it means the unrestricted policy files for the JVM you are using have not been installed. You can find these at http://www.oracle.com/technetwork/java/index.html at the same place as you downloaded the JDK/JRE (they're normally at the bottom of the page). Download the zip file Sun provide, follow the instructions, making sure you are installing the files into the JVM you are running with, and you should find the exception stops happening.
Note: providing maximum key sizes are not exceeded it is possible to use the BC provider without getting this exception. If it suddenly starts happening the first thing to check is the policy files.
There are specific example programs for dealing with Attribute Certificates, PKCS12, SMIME and OpenPGP. They can be found in the packages:
Another useful source of examples is the test packages:
There are also code examples from Beginning Cryptography with Java which demonstrate both the use of the JCE/JCA and also some of the Bouncy Castle APIs.
Finally, there are also links to books and articles on our resources page and further articles elsewhere on this wiki.
The lightweight library contains some compatibility classes in the java/* namespace to make development easier for compatibility between client/server code (otherwise the MIDlet would be org/bc/math/BigInteger and the Servlet would be java/math/BigInteger) as well as keeping the BC codebase as small as possible. This change was introduced a number of years ago, and announced on the BC mailing list. Since then, many users have been creating MIDlets using the cldc_classes.zip and the world is a happy place.
There is one, fundamental, important step that is required when creating a MIDlet. That is you must, must, must obfuscate the classes. If you do this correctly, everything works fine. If you do not do this correctly, your device/simulator will complain. Correctly in this case means that the package names also need obfuscating, not just the class names. The options for doing this are obfuscator dependent.
Here is a thread from a Nokia forum discussion how to do this in Netbeans.
RSA is not a regular block cipher, its operation is based on big integer arithmetic. As this is the case leading zero bytes will be lost since they are not meaningful (numerically speaking). You can get around this problem with RSA by using one of the padding mechanisms such as PKCS1 or OAEP. To do this in code with the BC provider you need to create the cipher as:
Cipher rsaCipher = Cipher.getInstance("RSA/NONE/PKCS1Padding", "BC");
Cipher rsaCipher = Cipher.getInstance("RSA/NONE/OAEPWithSHA1AndMGF1Padding", "BC");
If you create the cipher using:
Cipher rsaCipher = Cipher.getInstance("RSA", "BC");
it is actually up to the provider to decide what sort of padding you get. In the case of the BC provider this is none at all, equivalent to:
Cipher rsaCipher = Cipher.getInstance("RSA/NONE/NoPadding", "BC");
The RSA implementation that ships with Bouncy Castle only allows the encrypting of a single block of data. The RSA algorithm is not suited to streaming data and should not be used that way. In a situation like this you should encrypt the data using a randomly generated key and a symmetric cipher, after that you should encrypt the randomly generated key using RSA, and then send the encrypted data and the encrypted random key to the other end where they can reverse the process (i.e. decrypt the random key using their RSA private key and then decrypt the data).
DES keys actually include parity bits, one per byte, so a 64 bit DES key is in reality only a 56 bit one. The parity bits are ignored by the algorithm when it processes the key, so while you might decide whether a key is valid or not according to the parity bits, the value of the bits set aside for parity checking are not taken into account when initialising the cipher.
You may want to also ask yourself "why?" - it may not be worth it. If you want to build a provider, you'll need a Sun signing key if you are working with the Sun JCE or what you build will not work. This page contains information for those who are brave enough to tread this ground.
The BC jars for JDK 1.5 and later are all repacked using pack200 before signing, so they can be subsequently be packed/unpacked and still verify. You will need to specify --segment-limit=-1 (or -S-1) as an argument to pack200, otherwise there is a chance the signature will change.
At the moment, while we support all the algorithms, the answer is no. Up until recently it seemed unlikely we'll be able to do this as the costs involved are considerable and this is an all volunteer effort, however recently a charity has been established to take over the project and we are now able to raise funds to pay for certification. We now have a FIPS ready API and are offering early access to people and organisations who either donate to the project or hold Bouncy Castle support contracts through Crypto Workshop . We still need to raise around 40K USD for the final testing. If you are interested in donating to this effort you can donate at our donations page. Contact us at email@example.com if you would like further details.
At the time of writing (16 May 2007) Bouncy Castle is approved classified under ECCN code 5D002 and approved for export under License Exception TSU. If you also need to list algorithms available in the provider and the strengths supported, you can find the information in the specifications.html file provided with the distribution you are using. See The Bureau of Industry and Security website for further details.