Here’s a brief run-down of the changes:

• Probably the first change you’ll noticed is our new icon-based main menu. One of the biggest complaints we’ve had about Cryptnos is that the UI isn’t “pretty”. Version 1.3.0 improves things just a bit by adding a simplified main menu, as well as tweaking a few layouts and images to make things look a little better. It still won’t be winning any design awards, but at least it now looks like we put forth some sort of effort.
• Following on the heals of our 1.3.0 release of Cryptnos for Windows, we’ve added the other half of the new QR code import/export feature. If you have one of a number of recognized third-party QR code scanning apps installed, you can now transfer codes from device to device using specially formatted QR codes. The currently supported QR code scanners are ZXing Barcode Scanner, QR Droid, and QR Droid Private.
• Also mimicking Cryptnos for Windows, we’ve added the ability to selectively import sites from an export file. Gone are the days where it was all or nothing; now you can select any number of sites from a file, so it’s much easier (and less destructive) to import only certain sties from a file. You will also be warned if a selected site from the file will overwrite an existing site in the database, so there won’t be any nasty surprises.
• Issue #7 requested a new feature to show master and import/export passwords in plain text rather than obscuring them. This can convenient if you happen to have a very long, complicated master password and you’re using Android’s notoriously unhelpful on-screen keyboard. It can also be a big security risk, so this feature defaults to off, mimicking the behavior of previous versions. You can find the option to enable and disable this setting in the Settings activity.
• Finally, there were a number of little annoying bugs that have been needling me for a while which have been finally fixed. None of these were show-stoppers that greatly impacted usability, but I’m glad to see them finally fixed.

Here’s a quick run-down of the new features in this release:

• Probably the most interesting new feature is “daily use” mode. This is a new operational mode that drastically reduces the size of the Cryptnos UI for day-to-day use. The vast majority of the time, most users want only one thing from Cryptnos: to get in, get a password, and get out. They don’t need or even want to see all the details of which hash algorithm is used, how many times it’s performed, how the resulting digest is manipulated, etc. So “daily use” mode provides a toggle that hides much of the UI that is disabled when you check the Lock Parameters checkbox. You’ll see the site name drop-down, the master password box, the Generate button, and the generated password box. That’s it. Cryptnos for Android does something similar by offering a “Generate Existing Password” menu option that only displays these fields. If you need to do something more advanced, such as change settings, edit or add new site parameters, or import or export data, you can toggle “daily use” mode back off to get the full UI.
• Another new feature is the ability to export site parameters to a QR code. This is the first step toward the introduction of Cryptnos for Android 1.3.0, which will also include this feature. Cryptnos for Android will let you import and export site parameters from one device to another if you have one of a select group of QR code reading apps installed. Cryptnos for Windows adds the ability to export sites to a QR code, allowing you to import the site into an Android device equipped with Cryptnos just as easily. Note that since cameras are not as ubiquitous on desktops and notebook computers as they are on smartphones, the Windows client can only export to QR codes, not import. Special thanks go out to the ZXing team whose awesome barcode reader library enables us to do this.
• We’ve enhanced the import process so you can now pick and choose which site parameters in a file you’d like to import. Previously, importing was an all-or-nothing process; if you wanted to import only certain sites, you’d have to be specific during the export process. Version 1.3.0 will now display the site names of the parameters in the file and let you select which sites you’d like to import. If a site in a file will overwrite a site already existing in Cryptnos, you’ll see the site name appear in red in the import dialog. You’ll also be warned if you’re about to import a site that will overwrite an existing one. This is also a feature we plan to port to Cryptnos for Android 1.3.0.
• Now that “daily mode” makes the Cryptnos window much, much smaller, some folks might find it handy to be able to tell Cryptnos to float on top of other windows, even when it loses focus. This is especially useful for folks who prefer to type their passwords rather than copy and paste them, which is much less vulnerable to clipboard based attacks. Well, we’ve added a “Keep Cryptnos on top of other windows” option in the Advanced Settings dialog to do just that. This feature can easily be turned on or off, whichever you prefer. The default behavior is off, which is the same as found in prior versions.
• And although this is entirely under the hood and invisible to you, we’ve updated our copy of the Legion of the Bouncy Castle Crypto API to the latest version (1.7). I’m not sure if any of the bug fixes and updates included in this release affect us, but we’d rather be safe than sorry.

One cool thing about this release is that it gives our Android users a glimpse at some of the new features we’ll be adding to their client soon. Many of these ideas were things we wanted to add to the Android client first, but we just happened to tackle them on the Windows side first by chance.

All of the download links have been updated, which you can find either off the Windows page here or off the Google Code site. If you have update notifications turned on, you should be getting the notice sometime within the next week. Let us know if you have any problems by posting on the Google Code issue tracker.

I apologize that there hasn’t been much in the way of Cryptnos news lately, folks. Truth be told, there hasn’t been any news primarily because there hasn’t been anything newsworthy to report.

When I started working on Cryptnos, I did so to scratch my own itch.  I wanted a password manager where I didn’t have to rely on anyone else, where I knew precisely what was going on under the hood, that was completely Open Source and open to scrutiny. I built the Windows version and the initial itched was scratched. Then I acquired an Android phone and wanted to have the same power and flexibility while I was on the go. The Android client soon followed; the second itch was scratched. However, I was not content with limiting Cryptnos’ use to just Windows and Android, especially in situations when neither of these clients were available to me (such as accessing a secure site on my iPod Touch). Cryptnos Online was born; the third itch was scratched. I came up with a few additional ideas to improve each version, discovered a few flaws with the help of some very diligent fellow users, and incremented each of these clients through a number of successive iterations. That’s when silence fell.

Unfortunately, now that my personal itches have been scratched, development on all versions of Cryptnos have slowed to a crawl. The Windows and Android clients do pretty much what I wanted them to do and I haven’t had any requests for enhancements in several months. There are several things I want to do to improve Cryptnos Online, but since I use it rarely myself there has not been much motivation. I’ve also had a great deal of work piled upon me at my other two jobs (my “day job” as a .NET developer and my comic strip), chewing up any available free time for Open Source development. This lack of time has also stalled all work on the Java client, another effort that has been on indefinite pause primarily because it’s not an immediate personal priority.

Does this mean that Cryptnos development is coming to a complete halt? Absolutely not! I have a number of ideas on how I’d like to improve the UI of the Windows client to make it smaller and more compact for daily use. I also would love to enhance the Android client to make the experience on Honeycomb and higher tablets better. I certainly don’t want to leave the Java client unfinished. The problem, unfortunately, is that Cryptnos has always been a labor of love that is purely at the mercy of my extremely limited free time. Since Cryptnos does absolutely nothing to pay my bills, it has to take a back seat to the jobs that currently do.

So what does this mean to you? Well, since my personal itches have been scratched, the big takeaway here is that if there’s something you’d like to see in Cryptnos, please use our Google Code issue trackers to make your voice heard. There is an issue tracker for both the Windows and Android clients. If you have a suggestion that you’d like to see that may affect either client (i.e. something fundamental to how Cyrptnos works rather than how you interact with the interface), you may post your request to either list and I’ll cross-post if necessary. That said, if you do make a request, please be patient and I will address it when I can. I’d love to see Cryptnos be useful to as many people as possible, so your input is extremely valuable.

This isn’t a very important update for most folks, and frankly if you already have Cryptnos installed and it’s working fine, you don’t really need to update. This is mostly a fix for a quirk in the Android Market that was filtering Cryptnos out of the list of available apps when it really shouldn’t have been. Android assumes that a touch screen is required for all apps unless you explicitly say otherwise. Cryptnos has always been usable and navigable without a touch screen, assuming you have a trackball, D-pad, or some other device to scroll through the on-screen controls. However, because we didn’t explicitly go into the application manifest and declare that the touch screen wasn’t required, the Market assumed it was and filtered out of the list. Thanks to this change, Cryptnos is now compatible with at least 532 different Android-based devices (that Google knows about).

Over the past several weeks I’ve received a number of e-mails from several free software distribution sites. I won’t mention the names of these sites, nor will I link to them, to protect the innocent (or guilty, depending on your point of view). In each of these cases, the sites in question sent me a brief e-mail “congratulating” me on the inclusion of my software (both Cryptnos and its functional ancestor, WinHasher) into their download database. I was assured that my software had been “tested in [their] labs using several industry-leading security solutions and found to be completely clean of adware/spyware components”. (Well, that’s good to know. I would have never known that if they hadn’t told me.) I was presented with a nice graphic “to let [my] users know about this certification” as well as links to where they had “mirrored” downloads of both applications.

What bothers me about these notifications is that they were unsolicited. I did not contact any of these sites and request inclusion into their databases. That isn’t necessarily a problem; both Cryptnos and WinHasher are released under a GPL license, so redistribution is not only permitted but encouraged. What bothers me is that both applications are, from various standpoints, security applications and that the act of downloading security software, even when Open Source, from a third-party introduces risks that I’m not sure I’m comfortable asking my users to take.

Certainly I could take the assurances of these download sites at face value and assume that their download mirrors are secure and provide unaltered versions of my software. However, as someone who writes a security software product, that would be rather naive assumption to make. How can I be certain my application has not been compromised once it has left my server? While I have downloaded Cryptnos from at least one of these sites and compared its SHA-1 digest to that from our Google Code site, I have not yet been able to do so from any of the others, and I likely won’t be able to do so for every single release. For that matter, how am I to know it hasn’t been altered after I ran this test? Perhaps I am being overly paranoid, but in the realm of computer security, paranoid is the right frame of mind.

So I wanted to officially go on record by stating that the only official place to download Cryptnos releases is at our Google Code site. All download links on this site point to the Google Code site, both to conserve our bandwidth and to consolidate download count numbers. If you download Cryptnos from another site, you do so at your own risk. We cannot validate and authenticate every third-party download site, especially those we do not know about. You should always compare the cryptographic digest of these downloads against the digests posted here or at Google Code or, better yet, you should check it against the GnuPG digital signature posted for each release. If the digest or signature does not match, the download should not be trusted. This should go for all Cryptnos downloads, including those you may download from here. Since the digests and signatures posted here and at Google Code are “official”, they can be used to validate or authenticate third-party downloads. If you determine that a third-party appears to be trustworthy, then you may at your discretion continue to download Cryptnos from there in the future. However, you should still validate each release with the official one here to make sure you are getting what you think you are getting.

While we are grateful for the increased exposure and traffic these third-party sites have given us, we do so with an air of caution. This is only one official place to get Cryptnos, and everywhere else should be approached with caution until they have been vetted.

This is a small bug fix release to fix Issue #6 in the Google Code issue tracker. Although I thought there were enough checks in place to prevent this, it looks like there was a possibility that Cryptnos might throw an exception if the user’s preferred external file manager was no longer available. While I was unable to replicate the error itself, I could definitely see where it could occur. If the user’s preferred file manager is unavailable and Cryptnos does not detect this when the Import or Export activities are loaded, the button to launch the file manager may still be displayed (although it shouldn’t). If this occurs now and the user taps this button, Cryptnos will catch the exception, notify the user that the file manager could not be found, and ask them to check their preferred file manager setting.

This is mostly a minor bug fix release, although our statistics indicate that most folks will never notice the change. That’s because the bug involved only occurs on Android 3.0 (“Honeycomb”), and I strongly suspect I’m the only one even using it on a Honeycomb tablet yet. .  Full details can be found in the corresponding bug report, but it mostly stems from a change Goolge made to the Android APIs that only manifests itself on Honeycomb devices. In the process, we discovered another deprecated API that may cause problems in future versions of Android, so we took the opportunity to wrap that code in API-specific tests to prevent problems later on.

The thing that might interest non-tablet users is the addition of “Apps2SD” or “move to SD card” support. Android 2.2 (“Froyo”) added the capability for users to move applications to the device’s removable storage (such as SD or microSD cards) if the application supports it. Originally, we decided not to enable this feature for Cryptnos because we felt it might be a security issue to have the app and its data on a removable storage medium. After a careful review of how the feature works, however, we decided that our concerns were largely unwarranted. The actual database containing the site parameter data will still reside in the device memory and won’t be moved to the SD card, while the “bulkier” application code (which isn’t sensitive) can be moved. (If you can call Cryptnos “bulky”, considering it only takes up a few hundred kilobytes of space…). Of course, you’ll need a device running Android 2.2 or higher that has some sort of removable storage card installed to take advantage of this feature.

This release contains a minor, user-requested enhancement. Up until this release, Cryptnos for Android automatically copied generated passwords to the Android system clipboard after they’re recreated. The idea for this functionality was convenience; since Cryptnos passwords aren’t very friendly for retyping, copying and pasting them into an authentication form is a lot easier. However, this does pose a potential security risk; malware on the device can easily access the clipboard and copy any password currently stored there. However, Cryptnos for Android did not provide a means for disabling this behavior for users who prefer a higher level of security.

Cryptnos for Windows already contains a checkbox that allows the user to enable and disable this functionality, so it seemed natural to include it in the Android app as well. I’ve been planning to add this option for a while, but I just haven’t gotten around to it. After an official user request came in for it, it seemed silly to keep putting it off. You can find the checkbox under the Advanced Settings item in the main menu. The previous behavior remains the default, copying the passwords to the clipboard after generation.

This is a minor bug fix release. We recently received our first error report through the Market feedback mechanism. It was discovered that in certain situations, the import/export mechanism in Cryptnos may run out of available RAM. Ordinarily, this should never be an issue; Cryptnos export files are usually very small, mostly because the data itself is small but we also compress the data before running it through the encryption routine. I have personally never seen a Cryptnos export file that is more than a few kilobytes in size, and I have over 50 sites in my database. That said, it is theoretically possible for someone to accidentally (or even maliciously) try to import a file that is not a Cryptnos export file. If the file isn’t too large, Cryptnos would in general handle this well; it would produce an error message stating that the file was invalid. If, however, the invalid file exceeded the amount of available RAM, Cryptnos would try to load it and subsequently run out of memory, leading to a virtual machine error not normally caught by our usually thorough exception handling.

The primary cause of this problem was the fact that during import and export, Cryptnos had to hold the entire contents of both the encrypted and decrypted data in memory all at once. While there were checks in place to ensure that the file could not be larger than 2GB (certain API-dependent parts of the code relied on 32-bit integers), there was no check on the amount of available RAM. There aren’t any Android devices that currently have 2GB of RAM, but there are tons of devices that have as little as 256MB or even 128MB. If a user “accidentally” imported, say, a 600MB MPEG-4 movie, Cryptnos would dutifully attempt to open the file and decrypt it. Unfortunately, if the device only had 256MB of RAM and Cryptnos tried to allocate 1.2GB of RAM, that would result in an obvious crash.

With this release, we’ve made the following changes to the import/export handler to improve the situation:

• While the import routines are still required to hold the entire decrypted data in memory (we don’t want to write that to persistent storage anywhere), they now only read a tiny bit of the encrypted data from the import file at a time. This buffer is the same size as the block size of the underlying AES cipher, meaning the import routines use a lot less memory than they did before, practically half. Unfortunately, this optimization cannot be applied to the export code because we don’t want to write the unencrypted intermediate data anywhere persistent; we have to hold it in memory at least until it’s encrypted, meaning that both the unencrypted and decrypted data must be in memory at the same time, at least for a brief time. Fortunately, this shouldn’t be nearly as big of a problem for exports as it would be for imports because we know how much data we’re dealing with. Imports are far less predictable, especially given the scenario with the video file described above.
• Both the import and export routines now release memory objects much more quickly than they did before. We used to rely on the virtual machine’s garbage collector to clean up our mess, meaning our allocated objects could hang around for an unspecified amount of time after the import/export process is complete. We know explicitly deallocate large memory objects immediately after they are no longer needed, which should trigger the GC to free that memory sooner.
• In addition to the 2GB file size check, we now explicitly test to see if there’s enough RAM available to encrypt or decrypt the data before we start the process. It it looks like there’s not enough memory available, the user receives an error “toast”; they’ll have to free up some memory or try to import/export a smaller subset of data. Unfortunately, there’s not much we can do to assist the user here besides warning them. If their import file is exceptionally large (highly unlikely but not impossible), they may need to export the sites from the other Cryptnos instance in smaller chunks and import each chunk independently. However, this should protect us from “importing” that 600MB video file and crashing the app.

During testing this fix, we also discovered another bug in the old platform-specific, version 1.0 export format importer. I’m not sure if the bug was introduced by the fix above or if it existed prior to that, but we’ve fixed it nonetheless. During the import of an old-format export file, we found that Cryptnos would successfully import the data but would report that the file was invalid. This was because there was an extra line at the bottom of the unencrypted data, resulting in an extra “invalid site” at the end. This likely wasn’t affecting very many people because we didn’t have many users back in the version 1.0 days (the new cross-platform format was introduced in 1.1), but we certainly don’t want anyone depending on those files to have problems.

We’ve also updated the Legion of the Bouncy Castle code behind the scenes to the latest version. This shouldn’t have any impact to anyone, but there was one change in the way the BC handled encrypted output streams that might have potentially impacted Cryptnos export files. At any rate, moving to the latest version prepares us for when BC makes it’s jump to their next major version, meaning less upgrade hassles for us down the line. (Cryptnos only uses a small subset of their code which should be relatively mature and thus shouldn’t change frequently.)

We also improved the text in a few of the help sections, as well as fixed a few typos. Oopsy.

As always, the best place to find Cryptnos is in the Android Market. If you cannot install it from there for any reason, you can always download it here and “side load” it onto your device. Just make sure to subscribe to our releases RSS feed to keep up on updates if you do.