PreviousNext…

Debugging ciphers and the like

Phew, what a day of hacking, tweaking and general trouble-shooting. I’m going to post this particular experience if nothing else than for preservation in Google, as it took me quite a while to resolve this issue, even with the help of that very search engine.

At the moment, I have a requirement at work to sign and encrypt data using various algorithms, and I have plumped for doing this, in my local development environment at least, with the venerable Bouncy Castle crypto package. The Bouncy Castle stuff is rightly popular, and is thoroughly documented. Example code is provided, and the site contains a lot of additional resources for the developer just starting out with all this stuff… But that’s not why I’m posting of course. I’m posting so that some of the pain I endured today might be avoided!

Due to the nature of crypto classes, the relevant jar files tend to be signed, and there’s usually one other requirement. If you don’t meet this requirement, then get used to seeing something like this in your Java console:

java.lang.SecurityException: Unsupported keysize or algorithm parameters

This kind of exception crops up if you’re doing something with security and / or crypto-related classes, and haven’t quite got your environment right. This isn’t limited to Bouncy Castle either: JavaMail and various other third-party crypto packages can make you suffer too.

If you search the web for more detail on this error — including the Bouncy Castle mailing list archives — you will encounter, again and again, people telling you to ensure you’ve installed the unrestricted policy files for the Sun Java Cryptography Extensions (JCE).

Problem solved you’d think. Well, there’s one thing very little of the documentation tells you: when you download and install the Sun JCE unrestricted stuff (a small download, usually at the bottom of the page which features the JDK downloads): you need to ensure that you install the policies in the correct Java Runtime Environment (JRE).

I know what you’re thinking: “Duh, of course you do”. But the Sun pages all talk about installing this stuff to %JAVA_HOME%\jre\lib\security on Windows. That is, the JRE that comes as part of your standard install when you fire up the full Java Development Kit. However, what the docs don’t tell you is that you might want to check whether you have another JRE under c:\windows\program files set as your default. Doh! If you’ve installed the two policy files and are still getting nowhere, check!

Gah. Anyway, as part of the tinkering I was doing today, repeatedly running (and failing) the tests that come with the Bouncy Castle packages, I knocked up a test class to assess exactly what ciphers I had properly installed on my PC. Here’s a typical output from the class when only the basic “strong” JCE policies are in place (these come as standard with the recent Sun JDKs):

There are 6 ciphers in total
PBEWITHMD5ANDTRIPLEDES
DESEDE
AES
PBEWITHMD5ANDDES
BLOWFISH
DES

Set up the Bouncy Castle stuff too (for example), and you should see over eighty ciphers become available, assuming you’ve successfully negotiated the dual JRE issue. To see what I mean, you can download the class right here:

TestCiphers.java.

Enjoy.

Comments

  1. here's an excelent book about j2se and some j2ee security
    http://www.j2ee-security.net/Axel Janssen#
  2. By way of addition to the code I posted, this article offers a decent overview of symmetric encryption algorithms and has some example code to enumerate all the providers on a system (i.e. not just the ciphers as per my code):

    http://www.informit.com/guides/content.asp?g=java&seqNum=31&rl=1Ben Poole#

Comments on this post are now closed.

About

I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.

";