Posted tagged ‘Java’

Cirrus Android Widget for Weather Display Live

December 13, 2014

One of my recent projects was to develop an Android widget to display the values found in online WD Live clientraw.txt files. It accesses the same data as my other weather related code projects this year: a JSON Web Service for Weather Display Live and a PiFaceCAD Weather Display Console.

I’ve name the Widget “Cirrus” after the cloud genus. The widget supports 18 different weather data points (and displays the current trend for many of these) and 16 different measurement units. It also has colour coding for easy recognition of different temperature ranges (using the BBC Weather temperature colours) and UV index (using the US EPA UV Index colours).

Click to Enlarge

Click to Enlarge

I use the widget to display the current conditions for both my own weather station and others when I travel. So far I have installed and run it successfully on a Samsung Note II (Android 4.4.2), Samsung Galaxy Express (Android 4.1.2) and a 2013 Nexus 7 (Android 5.0.1).

At this time I do not have any plans to publish the widget on the Google Play Store. I have, however, open sourced the code using the MIT License and made it available via GitHub here:

https://github.com/waynedgrant/android-appwidget-cirrus

See the read me for installation and use instructions.

 

A History of KeyStore Explorer – Part Three

May 18, 2012

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.

This post continues from Part Two and concludes the history.

KSE Freeware

This history continues in late 2009. At the time version 3.4 of the commercial KeyStore Explorer (KSE) was under development but I was growing bored with it. Managing a business was losing its appeal and I was running out of ideas for new features.

First of all I resolved to close Lazgo Software as an enterprise so that I could reclaim the time it was taking to run it. However, before I could do that I would have to cease selling KSE. I was reluctant to go back to an open source model so decided to try something different again by making KSE freeware. This would allow me to keep the utility available to those who had paid for it and make it available to a larger audience without giving away my IP. After putting so much effort into the code I was reluctant to give it away again.

To differentiate the freeware version from the commercial versions I gave it a new major version number of 4.0. Despite the version jump the only difference between 4.0 and 3.3 was the inclusion of the minor features I had already developed for 3.4 and an absence of any licensing code. KSE 4.0 was released in April 2010. I started the process of killing Lazgo Software Ltd immediately after that.

With version 4.0 released I started development of 4.1. I wanted to see if I retained any interest in KSE now that I was free of the shackles of the business. The focus of 4.1 was to expand the selection of signature algorithms to include the various extended length SHA variations. This would be tricky as it would require an upgrade of the Bouncy Castle libraries and therefore the provision of a mechanism for users to upgrade their JRE’s crypto strength. I got some way through the implementation but it took many months to get there. Finally I simply ran out of steam. It was time to park KSE and come back to a decision on its future at a later date.

I took a break and dabbled in a few other pet projects instead. The most enjoyable was my time spent writing a turn-based zombie strategy game, inspired by the classic game Laser Squad, using Microsoft C# and XNA. That was great fun although I have never finished it. I did a lot of studying and dabbled in mathematics and meteorology. It was also during this time that I started blogging on topics including my experiences with scrum, agile and amateur meteorology. It was great having so much free time again. Nine months passed pleasantly without my touching KSE or deciding what to do with it.

Blogtastic

In September 2011 I picked KSE development back up again. I can’t remember why but I just had an urge one morning to start hacking away at it again. It was tough getting back into it after so long away. Nonetheless I quickly found I was enjoying it again. My enthusiasm for KSE was back and I resolved to get 4.1 out the door as soon as possible.

In the 18 months since 4.0 had been released I had noticed a marked increase in the number of downloads KSE was enjoying. It was a no-brainer working out why that was happening. An application will be more popular if it is free as opposed to paid-for. I reckoned that I may be able to leverage the application’s growing user base by combining it with my new-found interest in blogging.

The idea was to start telling users exactly what I had planned for KSE and to publicly invite suggestions for enhancements. Even if I ran out of ideas to progress KSE’s feature set a motivated user-base never would. In addition I could offer a beta test programme for 4.0 and get extra testing from real users. This would be a massive help to me if it worked out.

Using this blog I posted the development updates, invited users to submit enhancements and got a beta test program up and running. The reaction from users was pretty awesome. Many people gave up their time to test and submit bug reports and many more provided their own ideas to improve KSE. I have no doubt that the first beta test programme for 4.1 led to a better finished product. In addition the backlog of user submitted enhancements I am even now working through will continue this process of improvement.

Buoyed by the feedback I hammered through the remaining features of 4.1 making a final release available in March 2012. The expanded signature algorithm support was the main feature but many smaller enhancements were also included.

It is now May 2012 so that pretty much brings the history up to date. Work on 4.2 has started and is progressing well. Of the enhancements that will feature in 4.2 every single one is based on a user suggestion. I’m now confident that running out of ideas is no longer going to be an issue so I’ll be continuing development of KSE for the foreseeable future.

KeyStore Explorer 4.2 Proposed Features

April 24, 2012

After a not so fun time last week dealing with the ‘java.lang.IllegalStateException: no splash screen available’ bug I thought I’d post some positive KeyStore Explorer news. Specifically that I have settled on a set of features to comprise version 4.2.

They are as follows:

Secret/Symmetric key generation

Up until now I have neglected to add secret key support in KSE. However, now that even keytool supports secret keys I’m eager to catch up. From 4.2 KSE will be capable of generating 25 different types of secret key entries. This feature is already complete. See the screenshot below for a list of support algorithms.

Click to enlarge

Extended support for Key entries

Secret keys are stored in key entries within KeyStores. Key entries also support storage of lone private or public keys. Until now users of KSE have only been able to delete key entries regardless of what was stored within them. From 4.2 (where the KeyStore type allows it) key entries can be examined, unlocked, have their passwords changed, be renamed, be cut/copy/pasted and preserved when a KeyStore changes type. This feature is almost complete.

Examine CSR

Currently KSE allows CSRs to be generated and signed. In 4.2 it will also be possible to view their details.

Support more KeyStore file extensions

A basic change to support some of the rarer KeyStore file extensions in the various file dialogs (.jceks, .bks, .uber, etc).

Remember last file directory between sessions

Another basic (and self-explanatory) change.

Direct Certificate import and export from Certificate Details dialog

This feature will the direct import as a Trusted Certificate entry of any certificate from the Examine Certificate dialog. No more viewing the certificate’s PEM, exporting it and then re-importing it will be required.

Fixed: java.lang.IllegalStateException: no splash screen available

April 16, 2012

The issue I posted about last night, java.lang.IllegalStateException: no splash screen available, has now been fixed.

Simply uninstall version 4.1 and download and install the patched version 4.1.1.

Bug: java.lang.IllegalStateException: no splash screen available

April 15, 2012

Over the last few weeks I started noticing the following search term appearing in the lazgosoftware and this blog’s keyword search terms:

java.lang.IllegalStateException: no splash screen available

The search term appeared roughly once a day and seemed to suggest that some users were having an issue with KeyStore Explorer. Specifically, given the time frame of the searches, with the newly released version 4.1. However, I could not replicate the issue and none of the beta test users had come across it. Worse still, almost nobody was talking to me about it. A handful of people had reported it but only one of those was prepared to run any diagnostic commands (and that proved to be a dead-end as KeyStore Explorer suddenly started working).

After seeing the search term pop-up once again in my blog today I was getting more than a little frustrated. I knew there was an issue but had nothing to act upon. However, I spent some time this evening trying to replicate anyway. It is tricky trying to replicate an issue you have no details on it but I did manage it finally.

The error message suggested that there was an issue with the splash screen functionality. It turned out that if a user has never had a version of KeyStore Explorer installed before, has not upgraded their JCE policy files and is using Java 7 (rather than Java 6) that the following error dialog will appear after the license agreement and KeyStore Explorer will fail to start:

This explains why the beta test users never encountered the issue (they were users of previous versions) and why the one helpful user found that 4.1 suddenly started working (they subsequently installed and ran 4.0.1).

I have worked out a fix and will look to release it as soon as possible. In the meantime…

Workaround

  1. Download and install KeyStore Explorer 4.0.1.
  2. Start it and accept the license agreement then close it.
  3. Now you can happily run KeyStore Explorer 4.1.

KeyStore Explorer 4.1 Released

March 17, 2012

I am pleased to announce that KeyStore Explorer 4.1 has been released. I have been working on this release on and off (mostly off) for nearly two years. It is great to finally be able to distribute it. I intend to release more frequently going forward.

My thanks go to the beta test volunteers. The volunteers found bugs and suggested many improvements. Some of the minor improvements made it into 4.1. The meatier enhancements are slated for future releases. I intend to run beta test programmes for all future releases.

Note that to use version 4.1 you may have to upgrade the cryptography strength of your Java Runtime. I have built a wizard into KeyStore Explorer to guide users through this process. Complicating the setup of KeyStore Explorer was not a decision I took lightly. Unfortunately the upgrade is required for me to expand KeyStore Explorer’s feature set.

KeyStore Explorer is available to download from here.

Here are the new features that you can expect to find in 4.1…

New Features in 4.1

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

A History of KeyStore Explorer – Part Two

February 21, 2012

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.

This post continues from Part One.

Money Talks

This history continues in early 2004. At the time version 1.8 of the open source KeyTool GUI (KTG) was under development. Out of the blue I received an email from an IT Security company who had a proposition for me. The company was interested in integrating KTG into one of their products. However, KTG was licensed under the GPL which was not suitable for their purposes. Would I consider, for a fee, re-licensing the source code to them under their own license?

My answer was a maybe and negotiations commenced. This got me thinking. If a proper, grown-up company was prepared to pay good money for a source code license then perhaps end-users would pay for a commercial version of KTG. I decided that they might and started planning a new venture to test this out.

KTG would have to be forked, closed and re-licensed. I also decided to rename it. Firstly because “KeyTool GUI” was a bit of a naff name and secondly to reduce confusion when the tool became a paid-for offering. The plan was to stop working on the open source KTG and start working on the new commercial offering. I settled on the name “KeyStore Explorer” and got to work on finalising the features that had originally been earmarked for KTG 1.8 (notably unencrypted  PKCS #8 private key support). I also had to quickly implement runtime license support and a time-bombed evaluation mode. Source code obfuscation was also added and the code was re-licensed commercially.

(At the time I received some criticism for my decision to re-license the GPL’d KTG source code. Some people suggested that I couldn’t do this. Rather than engage in a debate I left them to their delusions. I own the copyright to the code whether it is licensed under the GPL or not. As such I can re-license it under another license should I choose. In addition my permission is required before any of my GPL code can be re-licensed under any other license. I plan to expand on this and the many other open source misconceptions I have encountered over the years in a future post).

I was determined to run the new venture legitimately and therefore formed a company: Lazgo Software Ltd. I had never run a business before but was looking forward to familiarising myself with the inner workings of a real company. I would have to get to grips with taxes, payroll, dividends, company accounts, marketing and everything else. It may sound perverse but all of this interested me purely because it was all so unfamiliar.

Next came web hosting, the company website and a simple integration with PayPal to enable purchasing. I had to get the hang of PHP and MySQL very quickly to accomplish all of this. Early 2004 proved to be a very busy time for me as I continued with my full-time employment.

Over this time a deal was agreed for a source code license with the IT Security company, contracts were exchanged and a tidy sum materialized in the Lazgo company bank account. I had an initial injection of cash and was ready to release KSE a few weeks later. Selling a single source code license was one thing. Would users pay for runtime licenses? I really had no idea at the time whether or not anyone would be interested in buying a license for KSE.

KeyStore Explorer

Click to enlarge

KSE 2.0 went on sale in May 2004. I offered single, five and ten user licenses as well as site licenses. Over the next few months I was pleasantly surprised to see the sales projections in my business plan smashed. It looked like there was a market for KSE after all and I duly got working on new features.  August and December 2004 saw the release of versions 2.1 and 2.2 respectively. In these versions many UI improvements made an appearance, the Help feature was greatly improved with the introduction of Java Help and functionality relating to CSR, JAR and MIDlet signing were all added.

Providing new features so quickly proved to be a good move when KTG was again forked, but not by me. While I worked on KSE I had abandoned my open source work on KTG. However, there was nothing to stop others from continuing my work. That is, after all, one of the main advantages of open source. I suddenly had competition in the form of Portecle. This was essentially KTG under a another name and again licensed under the GPL. I could also expect the maintainer of Portecle to to start adding new features in future releases. I reckoned that I would have to work very hard to compete with a free offering. To be competing with my own work was odd to say the least.

With sales going well I turned to streamlining the e-commerce side of the business. Initially I had manually fulfilled sales upon notification of purchases from PayPal. This quickly became unsustainable. I moved away from PayPal and signed up with a professional web payments service with a better integration offering. I carried out work to fully automate all aspects of purchasing with license keys and invoices being automatically emailed out on purchase. With most of the drudgery of sales eliminated I had more time to focus on the product.

Click to enlarge

Three more releases followed between March 2005 and February 2006 taking KSE to version 2.5. I focussed on support for new key formats including encrypted PKCS #8, and Microsoft’s hideous PVK private key format. I also invested time and money in making the product look more professional. First impressions are everything and I had to make KSE look as slick as possible if I was going to persuade users to part with their hard-earned cash. It is my belief that the best application in the world will struggle more than it should if it does not look professional.

To describe KTG’s icons as amateurish is being generous and they were still present in KSE up until 2.2. I tackled this by purchasing a license for the excellent Icon Experience icon set and integrated those into version 2.3. I also reworked the splash screen and was quite pleased with the results.

Besides enjoying the development and creative sides of KSE I really thrived on progressing my business skills. During the time KSE was available commercially I experimented with different price-points, promotions and carried out marketing via Adwords. Everything was a new experience to me and that in itself made it all enjoyable.

KSE: TNG

With the release of KSE 2.5 I decided it was time for some major changes in the product. I had basically been piling features onto the same old creaky UI that had been created for KTG. There were many areas ripe for improvement. At the time the tool sported a single document interface which was unacceptable for a modern application. Users could not utilise copy/paste or drag and drop in the application either nor was there any undo/redo support. Installation options were also lacking with only Windows or manual installations available. The application was written in Java and worked perfectly well on Mac OS X and Linux so why not cater directly to those users? As a commercial application, users would expect all of these features and more.

Click to enlarge

KSE versions 3.0 – 3.3 were written and released between March 2006 and November 2009. I included many new features including a tabbed multiple document interface, cut/copy/paste support, drag and drop export, undo/redo, a Mac OS X disk image, a Linux/Unix self-extracting install, a new Quick Start welcome UI, Tip of the Day, support for many new key and certificate formats (PKI Path and SPC certs, Netscape SPKAC CSRs, OpenSSL keys), support to edit X.509 extensions and many more improvements too numerous to mention here. I also continued to improve the look and feel of the application with custom icons commissioned from Iconaholic (see the modern KSE application and KeyStore icons for examples of their awesome work) and continued by obsession with tweaking the splash screen.

Click to enlarge

For the first time KSE felt to me like a grown-up desktop application. In addition I was miles ahead of any of the competition in terms of features (many open source keytool UIs had sprung up in the intervening years). I had invested heavily in terms of my time and reinvested some of the profits wisely in terms of icons, third party libraries and the many books I had studied over the years on general security, PKI, UI design and business. However, it was all worth it. Sales were still good and I could now say that I knew how to run a profitable business.

Unfortunately by late 2009 a lot of the fun and excitement had evaporated. I had greatly enjoyed the experience up until then but was growing a little bored with running Lazgo Software. I had streamlined all I could but increasingly dreaded my quarterly weekend session with the accounts, dealing with the tax man and the plethora of other really dull things that are involved in running a business. Running the business was not a challenge any more, just a bit boring. Worse still I had no idea what direction I could take KSE in. It supported every relevant crypto format and was feature rich. It just seemed done to me.

So the business definitely had to go. When something isn’t fun any more it isn’t worth it no matter the money it brings in (when I told people this at the time they looked at me like I was nuts, maybe I am). I still had to decide what to do with KSE, however. I will detail what happened next when I conclude this history in part three.

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.

Inception

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.