Archive for the ‘KeyStore Explorer’ category

KeyStore Explorer 4.1 – Beta Test Update, Some Thoughts on User Feedback

January 29, 2012

Last month I announced a beta test programme for KeyStore Explorer 4.1. The concept of user base driven beta testing is a new one for the KeyStore Explorer (KSE) project. Previously I have made do with my own (very extensive) pre-release testing. However, doing this testing alone was starting to bother me as I am not a day-to-day user of the tool. With some trepidation I therefore decided to take the plunge and set up the beta test programme. One month on I am glad I did.

The response so far has been very good. A handful of users have signed up and started using beta 1. One major bug was identified by a volunteer tester and has been fixed for beta 2 which I pushed out yesterday. In the process of investigating that bug I myself found a couple of minor issues which have also been addressed. This in itself would justify the beta programme for me. However, there has been another important pay-off: enhancement requests.

I have always stated on the KSE website that I am open to enhancement requests via the site’s contact form. However, I have received relatively few suggestions over the life of the project (a handful a year). Most of these have made it into KSE in one form or another or were already on the next version’s backlog as they were natural evolutions of the current feature set. I got to thinking that perhaps the users did not expect more from the tool, that it was mature enough and served their needs efficiently. The beta testers have shown me that this is not the case.

The beta test users have been making lots of suggestions as to how KSE can be improved. I have been taken aback by the amount of feedback I have received in such a short space of time. The great thing is that the suggestions are solid because they come from real users of the tool. I will attempt to incorporate some of these in 4.1. However, those that don’t make it in will be added to 4.2.

The lesson I have learned from this experience is that I can only elicit feedback from the user base if I make the effort to directly communicate with them. Simply sticking a contact form on the website and saying that I welcome feedback is not enough. It is too impersonal and reminiscent of the forms that appear on many corporate websites. Sites where requests appear to be being sent directly to /dev/null for all the response you get.

The beta test programme and my recent blogging about KSE have certainly been steps in the right direction. I will also look into other ways to engage KSE’s users going forward.

So if you want a say in the future direction of KSE then let me know. You can use my impersonal contact form or just leave a comment on any of the KSE blog posts. I do read enhancement requests and, where they make sense for the wider user base, implement them.

Also, I am still accepting beta testers. Nothing would make me happier than for you to break KSE. The more the merrier.

KeyStore Explorer 4.1 Complete – Beta Testers Required

December 27, 2011

I posted last month on the development status of KeyStore Explorer 4.1. I am now happy to report that all of the deliverables described in that post have been completed. The next step is system testing which normally takes me several weeks (sometimes months if I am short of free time). I have a large and growing spreadsheet of test cases that I work through and this is a very time consuming process. The pay-off for such thorough system testing is that I rarely receive bug reports so it is worth the effort. My aim to have a fully tested version 4.1 ready for release by the end of Q1 2012 at the latest.

Since KeyStore Explorer went freeware I have seen downloads for the tool rise to 1,500 a month. With such a potentially large user base I think that it may be viable to have a beta test programme this time around. This programme could run concurrently with my system testing and provide additional feedback and test coverage from real users.

What I need are active users of KeyStore Explorer to simply use it as they would any final released version. Such beta testers would be willing to provide me with feedback on bugs and anything about the new features that is or is not working out for them. This type of third party testing is especially important for this release because of the requirement for some users to upgrade their JRE’s crypto strength in order to use 4.1. I have tried to make this process as pain free as possible within various limitations but would really appreciate feedback on it. If the beta test programme proves to be popular I will run it for every new release.

If you are interested in trying out 4.1 early then get in touch via the Lazgo contact form supplying the following details:

  • Your name and email address
  • The subject line ‘Beta Testing’
  • In the description please provide details of the JRE version(s) and operating system(s) you will be testing
  • Which features you will be likely to utilise

I will be making a beta version available to interested users in early January.

My thanks in advance to all who help out.

A History of KeyStore Explorer – Part One

December 22, 2011

KeyStore Explorer (KSE) has existed, in one form or another, since 2002. These days it is a freeware offering but it has not always been that way. KSE started as an open source project before morphing into a commercial project. It is only relatively recently that it was re-licensed to be free for all to use once again. As the utility is now almost ten years old I feel it is a good time to write a potted history of KSE.


Back in mid-2001 I was a relatively green programmer with only four years of industry experience, mostly in C/C++ and RDBMS. I had just joined an ISV in Glasgow to cross-train as a Java developer. Many things interested me about the language notably its simplicity when compared to C++, the principle of Write Once Run Anywhere (WORA) and the cross-platform GUI toolkit: Swing.

(WORA and Swing are much maligned but not by me. If you put in the effort into each you can reap the benefits. I may dip into these topics in later postings).

All was well in my world. My employer looked to be going places, the fallout from the Dot Com bubble hadn’t yet bitten and I was working with interesting technology. However, to get the full benefit of working with Java and Swing what I really needed was a side-project, something outside of work where I would be free to develop as a chose, free from interference. As a bonus it would be great if the side-project was something new. The last thing I wanted to do was write yet another text editor or world clock, something that had been done a hundred times before.

It was then, in the course of my day job,  that I came across keytool. What keytool did intrigued me as I had no previous exposure to Cryptography. How it presented itself, on the other hand, with its ugly command-line interface provided me with an opportunity. I decided I would use Swing to recreate keytool in the form of a friendly GUI. I did some research and discovered that nobody had yet written a decent GUI alternative for keytool. I had found my side-project.

Thanks to the Way Back Machine I have been able to retrieve my exact thoughts at the time. Back then I wrote on the original tool’s website under the heading of “Why Bother”:

“As mentioned above Sun already supply keytool with the Java SDK and the KeyTool GUI is just a GUI implementation of (approximately) the same functionality. So why bother?

I found keytool to be a bugger to use with it’s many and various options. Command-line tools are, after all, invariably harder to use than equivalent GUIs. Secondly keytool forces its users to type in keystore and protected entry passwords in the clear on the command-line. This, of course, defeats the whole purpose of protecting keys in a keystore in the first place! Thirdly I needed a wee project to get me up and running using Swing.

So in an attempt to create an alternative to the command-line keytool utility (and get some practise with Swing) I’ve put together the KeyTool GUI.”

KeyTool GUI

Click to enlarge

So KeyTool GUI (KTG) was born with the aim for the application being that it not be “a bugger to use”. At first progress was slow as everything was new to me. My Java experience was limited, as was my exposure to GUI programming and UI design and I knew next to nothing about cryptography or PKI. However, it was great fun developing all these new skills. My core Java skills improved far more rapidly than they would have done through my day job alone. I also greatly improved as a UI designer by learning as much as I could from existing applications and various publications. However, what turned out to most challenging was the world of cryptography and PKI. Fortunately with the aid of many books and the Java Cryptography Extensions (JCE) and the Bouncy castle JCE provider I was able to progress in this area rapidly.

Early on I decided to open source my efforts so that others could benefit from my work. I settled on the GPL without too much thought. The idea of open source was new to me too and it struck me as being the most popular license at the time.

I worked for a year to produce version 1.0 releasing alpha and beta candidates during this time. When released in April 2002 version 1.0 was fairly feature rich allowing users to utilise a UI to create, modify and save JKS KeyStores. They could also generate RSA and DSA key pairs, import trusted certificates, create CSRs, import CA Replies and delete and rename KeyStore entries. In other words, the core functionality of keytool.

Over the next 20 months six more versions were released culminating in version 1.7 in January 2004. Many additions were made during this time including extending KeyStore support to include the JCEKS, PKCS #12, BKS and UBER types, the ability to examine Certificates and CRLs, CA Certificates support, PKCS #12 key pair import, a Windows installer as well as many usability improvements.

By version 1.7 KTG could be described as a complete replacement for keytool. However, there was still plenty of room for improvement so I planned to release more versions. After all there was no reason to be limited to simply imitating what keytool could do. Some of the improvements planned included converting the single document interface to support multiple files, to extend support to include more crypto algorithms and file formats and to create installers for other platforms like Mac OSX and Linux.

Click to enlarge

Also, despite effort being lavished on making the UI easy to use, it was still a bit ugly, especially in the icon department. The icons were  those provided by Sun’s look and feel guide for Swing and some I had cobbled together myself. I had no idea how I could source high quality icons but I was determined to improve what was in KTG at the time. However, I still like the splash screen that I put together for KTG which featured my own set of key ring. In fact I still use the swiss army knife featured on the splash screen above.

Regardless of its limitations the tool was proving popular with over 2,000 downloads a month and I received overwhelmingly positive feedback from users. This helped spur me to carry on development.

In early 2004 I was working on KTG 1.8. Despite this version 1.7 proved to be the last version of KTG released as 1.8 never saw the light of day. I will detail why KTG was abandoned when I continue this history in part two.

KeyStore Explorer 4.1 Development Status Update

November 21, 2011

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 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.

KeyStore Explorer 4.1 Proposed Features

September 17, 2011

After a nine month hiatus I am back working on a new version of KeyStore Explorer: 4.1. Included below are a list of the new features I intend to include in the release. The majority of these features were in place before my break but some have yet to be implemented. In addition the Bouncy Castle version upgrade presents some interesting challenges to the initial setup that I am still working on (i.e. how do you allow users to upgrade their security policy files without their having to get their hands dirty and when they do not have admin access by default? I have some ideas…). With the work still to be done and my usual fastitdious amount of testing ahead I cannot yet commit to even a rough release date. However, watch this space for more details including a possible beta test programme.

The Proposed Features

Double maximum RSA Key Pair Generation size from 8192 bits to 16384 bits.

Upgrade to latest Bouncy Castle version.

Support 11 new signatures algorithms for Key Pair Generation, CSR Generation and CSR Signing:

  • 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.
  • SHA-224 with DSA.
  • SHA-256 with DSA.
  • SHA-384 with DSA.
  • SHA-512 with DSA.

Configurable Trust Check settings for:

  • Import Trusted Certificate.
  • Import CA Reply.

Allow the removal of certificates from the end of a key pair entry’s certificate chain.

Make thumbprints selectable and expand choice of thumbprints (applies to Certificate Details dialog).