KeyStore Explorer 4.1 Development Status Update

I’ve been working on version 4.1 of KeyStore Explorer over the last two months. I thought now would be a good time to give an update as to where I am with the new features and what they will provide to users.

Note that if you have an idea for a new feature or have found a bug then let me know.

1 – Double maximum RSA Key Pair Generation size from 8192 bits to 16384 bits – COMPLETE

This was a simple change to double the possible key size of generated RSA key pairs. Don’t expect the generation of such large key pairs to be quick, however. On my Macbook Air (not the most powerful machine I grant you) a 16k bit RSA key pair takes 50 minutes to generate.

2 – Upgrade to latest Bouncy Castle version – COMPLETE

This was quite an involved change but a necessary one. KeyStore Explorer has been making use of an old version of Bouncy Castle for a long time. This was a deliberate choice on my part as the later versions of Bouncy Castle require that users upgrade the Jurisdiction Policy files in their JDK. I didn’t want users to have to do this to use KeyStore Explorer. However, as time has gone on the Bouncy Castle has added useful new capabilities which I am keen to take advantage of in KeyStore Explorer. The main driver for the upgrade has been the availability in Bouncy Castle of 11 new signature algorithms (see below).

There are two reasons this change was so involved.

Firstly I need to provide a simple mechanism for users to upgrade their Jurisdiction Policy files. I’ve added a feature for that which is described below.

Secondly the latest version of Bouncy Castle (1.46) deprecated many areas of the API which KeyStore Explorer makes use of in favour of new classes (namely X.500 names and X.509 Certificate Generation). I have a zero tolerance approach to code warnings and so spent a lot of time converting my code to use the new classes. I could have peppered my code with @SuppressWarnings(“deprecation”) annotations but, in my opinion, this should only be a last resort. Besides, with the next planned version of Bouncy Castle being version 2 I suspect that the deprecated classes will soon disappear. Therefore I want to get rid of KeyStore Explorer’s dependency on them sooner rather than later.

3 – Support 11 new signatures algorithms for Key Pair Generation, CSR Generation and CSR Signing – COMPLETE

The current choice of signature algorithms is sparse in KeyStore Explorer so I am adding 11 more. Some of these are more secure than those in place at the moment. This makes this change a no-brainer despite the pain around the Bouncy Castle upgrade and the Jurisdiction Policy files. The new signature algorithms are as follows:

DSA: SHA-224 with DSA, SHA-256 with DSA, SHA-384 with DSA, SHA-512 with DSA.

RSA:  RIPEMD-128 with RSA, RIPEMD-160 with RSA, RIPEMD-256 with RSA, SHA-224 with RSA, SHA-256 with RSA, SHA-384  with RSA,  SHA-512 with RSA.

4 – Configurable Trust Check settings for Import Trusted Certificate and Import CA Reply – COMPLETE

Certificate imports in KeyStore Explorer come with the same chain of trust checks that keytool does. These checks are worthwhile but users may want to switch them off for convenience. This change allows them to do this on a feature-by-feature basis via the Preferences dialog.

5 – Allow the removal of certificates from the end of a key pair entry’s certificate chain – COMPLETE

Currently KeyStore Explorer makes it possible to append compatible certificates to the end of a key pair entry’s certificate chain. So why not allow the removal of end certificates? This change makes that possible.

6 – Make thumbprints selectable and expand choice of thumbprints – IN PROGRESS

Currently the certificate details dialog in KeyStore Explorer displays only MD5 and SHA.1 derived fingerprints. I am adding a new fingerprints control to the dialog which will allow the display of fingerprints based on any one of 11 different digest algorithms. This feature will add flexibility and reduce the height of the dialog.

7 – Jurisdiction Policy files upgrade – IN PROGRESS

To use the latest version of Bouncy Castle requires the user’s JRE to contain the Unlimited Strength  Jurisdiction Policy files from Oracle. Unfortunately all JREs (apart from those shipped by Apple) come with the hobbled, limited versions of the files. The upgrade involves downloading the unlimited files from Oracle and replacing the limited versions in the lib/security folder within the JRE installation. I am attempting to simplify this process by:

  1. detecting on startup that the limited files are being used
  2. displaying a dialog to allow upgrade
  3. the dialog spawns a browser that goes to the appropriate unlimited jurisdiction download page at oracle.com for the user’s jre version (I am forbidden by Oracle  from hosting or redistributing the files myself)
  4. the dialog can receive the downloaded unlimited jurisdiction policy zip via drag and drop
  5. perform the upgrade for the user backing up the limited files and replacing them with the unlimited ones
  6. restart KeyStore Explorer

This is all in place. However, there are permissions issues with KeyStore Explorer carrying out the upgrade on Operating Systems like Windows 7. I have some ideas to resolve these issues which I am progressing with.

Advertisements
Explore posts in the same categories: KeyStore Explorer

Tags: ,

You can comment below, or link to this permanent URL from your own site.

4 Comments on “KeyStore Explorer 4.1 Development Status Update”

  1. Victor Says:

    Thanks for the update.
    Keep up the good work.

    Victor Rosenberg

  2. JL Says:

    I so appreciate you and your work. Keystore Explorer has saved me immense time compared to the poor alternatives available (Portecle withstanding, which I understand was also yours).

    Thanks so much.

  3. Eric Lee Says:

    I’d like to try Keystore Explorer but can’t get past the “Upgrade Cryptography Strength” dialogue. Our JREs ALWAYS have unlimited strength installed and this dialogue offers no indication of how it came to this decision or an option to carry on. Naturally, running on a Unix server machine, it would not have permissions to alter JRE files.

  4. Eric Lee Says:

    Well I should be more careful! I was of course finding the wrong JRE on PATH which indeed didn’t have unlimited strength jars. All good now


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: