Recently, the following comment was made in the Android Market for Cryptnos for Android:

Works as described, but I can’t select required parameters like: must be 6-8 characters, contain at least 2 letters and 2 numbers.

I look upon this as a feature request, even though the commenter did not formally ask. That said, I thought this was also a great opportunity to showcase Cryptnos’ flexibility and demonstrate how a “missing feature” isn’t necessarily missing after all.

First and foremost, let me say one thing: the length restriction is technically a non-issue. Cryptnos does have a Length Restriction field (“Use only the first x characters” in Cryptnos for Windows). If a minimum and maximum length is set by the service you wish to authenticate with, simply set the Length Restriction field to the maximum value (in this case, eight) and that requirement should be met. Whenever you have a character length range requirement for a password, always go for the longest password you possibly can as this will be inherently more resistant to brute-force attacks. Each character you add exponentially increases the complexity and thus time to attack. Cryptnos will be doing the work of “remembering” the password for you, so aiming for the minimum length of a password compromises your security for no valid reason.

However, there is nothing in Cryptnos to enforce rules for more detailed character requirements, aside from the general options listed under Character Restrictions. In other words, there is no way to specify “at least 2 letters and 2 numbers”. For this specific example, this is also likely not an issue; Cryptnos passwords are Base64-encoded data, so it is statistically unlikely that a password will be generated with zero or one of these specific character classes. Likewise, Base64 data is mixed case, so it is unlikely that a password would be generated with only one case (i.e. all lowercase or all uppercase); mixed-case passwords are another common requirement like this. There are two symbols in Base64 (in our case, the plus sign and forward slash), which may statistically be less likely to appear than alphanumerics, but it is still unlikely that an eight-character password wouldn’t contain at least one.

This is, of course, easy enough to work around without modifying the application. If a specific combination of site token and master password does not meet these requirements, slightly changing one or the other will generate a vastly different password that probably will. Choosing the most inclusive Character Restriction setting (“All generated characters”) will ensure the greatest likelihood of meeting the requirement. If you feel strongly about the site token and master password used, incrementing the Hash Iterations setting will generate something new that is also very probable to meet the requirement. Since site token, character restrictions, and hash iterations are all saved with your parameter data, only changes to the master password require extra effort on the part of the user. As a last resort, of course, nowhere is it stated that you can’t modify your generated password manually before actually using it; on the contrary, we actually suggest that in the FAQ. You can always substitute a zero for a letter O, or a four for an A, etc.

Still, I look at this comment as a request and I’ll treat it as such. This will be a complex one, because it would require logic, UI, storage, and import/export changes. It would also require changes to all versions of Cryptnos for the applications to remain in sync. I’ll have to think about whether or not to implement this one. If you’d like to share your thoughts, you may either comment on this post or comment on the associated issue on the Cryptnos for Android Google Code site.

We are happy to announce that Cryptnos for Windows 1.1.1 is now available for download. This is mostly a bug fix release, which hopefully addresses the update checker issue previously reported. Unfortunately, I’m not 100% sure this fixes the issue, as only one person has reported it and I haven’t heard back from her in a couple months. If nothing else, there is a lot more error checking going on in the update checker now, so hopefully it will not crash Cryptnos completely if something goes wrong. If it does, the steps to disable the update check listed in the news item linked above will continue to work.

The only other outward facing change is a minor improvement to how Cryptnos reports problems with copying passwords to the clipboard. There is a known problem in Windows that many people believe to be something Microsoft broke in XP Service Pack 3 and beyond that causes the clipboard to fail to copy something intermittently. Microsoft denies the issue, but it’s been reported so many times that many people agree that it’s a problem with the OS, not the applications. We here behind Cryptnos concur, as we’re following all the appropriate steps to copy the password to the clipboard (one lousy line of code) and it usually works. It’s just sometimes… it doesn’t. Well, the error that pops up when this occurs is a bit more informative now as we’ve isolated this step from all the others and we can catch its errors separately.

Cryptnos for Windows 1.1.1 is still compatible with Cryptnos for Android 1.1.0, which hasn’t changed (yet). We’re going to try and keep these guys in sync at the major and minor version numbers, leaving any version numbers beyond that for bug fixes and possibly revision numbers. Thus, 1.1 is 1.1, no matter what comes after it, and Windows 1.1 should be equivalent in functionality to Android 1.1.

Just a quick note to announce that, after much soul searching, I’ve decided to set up Google Code projects for both Cryptnos for Windows and Cryptnos for Android. This is primarily for two reasons: (1) Google Code allows us to host our Subversion repositories for these projects publicly, allowing anyone to check out the latest code as it’s being developed and hopefully improving participation and contributions; and (2) the built-in Issue Tracker allows us to track bug reports and enhancement requests quickly and easily. Of course, it’s always been within my abilities and resources to host these two services myself; I’ve built and used many private Subversion repositories in the past, as well as have experience with a number of issue tracking applications. That said, Google Code is quicker to set up and easier to maintain, alleviating the headaches of having to manage and police the repositories myself.

So I officially request all bug reports and enhancements requests for these projects be posted to the relevant Issue Tracker on Google Code. If you’re interested in more rapid code updates than you’ll get here, you can always check out and update your local Subversion working copy from the repo. I’ll continue to post official source snapshots here (as well as on the Google Code Downloads pages) for the time being. Official news and release information will continue to be posted here.

Of course, I’m sure it would help if I actually linked to the project pages. The links are now on the official page for each project, but here they are as well:

• Cryptnos for Windows at Google Code (Issue Tracker) (Repository)
• Cryptnos for Android at Google Code (Issue Tracker) (Repository)

I’m not sure if Cryptnos Online will get a similar page or not, but Cryptnos for Java should get one once the code gets close to release.

We’re happy to announce that Cryptnos Online 1.0 is now available. What is Cryptnos Online, you may ask? Why, it’s Cryptnos, only it’s online, of course.

As mentioned in the history section of our About page, Cryptnos has gone through many iterations, including a browser-based, fully online implementation. I originally wrote that first draft as a means to generated passwords on my old trusty Palm Treo 700p, for which I was never able to develop code. (I always meant to dabble in Palm OS development, but since Palm OS as a platform is no longer being supported, the point is sadly moot.) I wrote that version as server-side PHP, which worked well for my own uses but wouldn’t work well for others. (“You want me to type in my password generating information into this form and you’ll make up my password and send it to me? I don’t think so…”) Cryptnos eventually made its way to Windows and then Android, but I knew I wanted to make it available to as many people as I could. Java would be a great start, but it still wouldn’t help everyone.

Enter Cryptnos Online. Virtually every platform has a Web browser, and virtually every Web browser supports JavaScript at some level. If I could write a version of Cryptnos that worked within the browser, that would make it accessible to everyone.

Cryptnos Online isn’t perfect. It’s not as full-featured as the other clients. It will not store your parameter data. It does not support all the hash algorithms of the full clients. It also requires an Internet connection, obviously, which doesn’t help in situations where you can’t get online. That said, it does the job and does it reasonably well. It’s definitely better than nothing, and hopefully even better than that.

As always, feel free to give us feedback. We’d love to hear your thoughts on how we can make all of our Cryptnos products better.

As mentioned in the FAQ, all versions of Cryptnos do (or will) store all your password generating parameters, with the important exception of your master password. The master password is NEVER stored, and neither is it ever checked for validity. Cryptnos has no concept of whether you master password is “right” or “wrong”; it’s just an extra “salt” of information stirred into the pot to make the soup that becomes your generated password more unique. Some might view this as a design flaw; after all, if you type in your master password incorrectly, your generated password might be “wrong”, resulting in a login failure. We, however, consider this a feature, and here’s a nifty trick you can use to take advantage of it.

Consider, if you will, a popular remote access service that allows you to access your desktops at home from anywhere. You simply install their server software on your machines and whenever you need to access them remotely, you log into their website and select the computer you wish to connect to from the list.  Their server creates the initial connection between the client and the remote machine, then hands over control to the pair to let them communicate directly once the connection is established. Naturally, you’ll want to protect this account with a strong password, and Cryptnos will happily step in to help.

For this scenario, the default parameters appear to be sufficient:

• Site: PopularRemoteAccessService.com
• Master Password: “My super secret master password”
• Hash Algorithm: SHA-1
• Hash Iterations: 1
• Character Types: Use all generated characters
• Character Limit: None (or zero)

So you create your account using this generated password. Great! You’re in. Now it’s time to set up the individual machines. You have several you’d like to access remotely; perhaps you have a couple at home, your parents often ask for help with their computer so you’d like to install it there too, you’re constantly helping your in-laws with their computer so it makes sense to add it to the list, and on rare occasions you even need to help out your sister half-way across the country. That’s five machines you’d like to associate with your account, and the service is happy to oblige you (for an additional fee, of course). Unfortunately, the installation process requires a separate password for each machine as an extra security measure. Being a security conscious person (you do use Cryptnos, after all), you have no problem with that. It’s just you’d hate to clutter up your Cryptnos site list with individual parameters for each machine.

To quote Douglas Adams: Don’t panic. Remember what we stated above: Cryptnos doesn’t care about your master password. So what if we kept the same parameters we used for the account password, but just changed the master password to something else, like the name of the machine we’re going to access? We can even combine that name with another short, easy to remember password for additional security. Consider the following, assuming the machines are named after the characters in a popular comic strip:

By changing only the master password, you can now reuse the same parameters as the main account password without adding an additional five sets of parameters to your database. There’s no need to modify any of the saved parameters, so you can keep the “Lock Parameters” setting turned on (for the Windows and Java clients) or just use “Generate Existing Password” (for Android), protecting those settings from fat-fingering. Since the inputs will be subtly different for each machine, the cryptographic hash will produce a dramatically different pseudo-random password for each one, unique for each machine and distinct from the overall account password.

This, of course, is just one example of the many permutations you could use for this scenario. If your machines are numbered, you can use that number as the number of hash iterations. (There are limits on this option, of course; you’ll need to specify a number for the account password, and excessively large numbers could lead to performance issues.) You could also pick a different hash algorithm per machine. These, however, modify your parameter settings and require a little extra effort on your part to keep track of what changes are associated with which machine. However, this should give you an idea of what you can do with Cryptnos. You can create an entire set of related passwords, still just as unique and strong, without a lot of extra effort.

What other creative ways have you come up with for using our program?

We have a report of what seems to be major bug in the update notification code in the recently released Cryptnos for Windows 1.1. If after installation you get a rather cryptic “Object reference not set to an instance of an object” error that prevents Cryptnos for ever starting, you’ve likely encountered it. It does not seem to be affecting every user. It’s going to take me a while to take a look at it and fix it, but we have found a way to bypass the error so you can get Cryptnos 1.1 to work.

A few warnings up front: This workaround will completely disable the update checking code until it is removed. You will have to manually check for updates while the workaround is in effect. You will also have to manually remove the workaround later to disable it. It requires registry hacking by hand. Modifying the Windows registry can be dangerous if you don’t know what you’re doing. If you are not comfortable making this change, please uninstall Cryptnos 1.1 and fall back to Cryptnos 1.0 until an official fix can be released. Note that Cryptnos 1.0 is unaffected by this issue.

1. Open the registry editor by going to the Start button and clicking Run.
2. In the Run dialog, type “regedit” and click OK. The registry editor will open.
3. Navigate to HKEY_CURRENT_USER\Software.
4. Look for the registry key folder “GPF Comics”. If it exists, open it. If not, create it. Note that this is a folder, not a key/value pair.
5. Under “GPF Comics”, look for the registry key folder “Cryptnos”.  If it exists, open it; if not, create it.
6. Inside this “Cryptnos” folder, right-click to bring up a context menu. Select New → DWORD Value.
7. Name this new key “DisableUpdateCheck”.
8. Double-click the newly created key. Give it the value of 1 (the number one). Click OK.
9. Close the registry editor.
10. If you have multiple logins on this computer, this hack will only affect the currently logged in user. You will need to apply this change to all users on the system to make Cryptnos usable for those users.

This should bypass the update check on start-up and Cryptnos should load successfully. Note that when we finally release the fix, you will need to manually remove this registry key value to re-enable the update check.

Sorry about this bug folks. This is one of those things that worked well in all our testing but only seemed to surface when we released the code into the wild. Immense thanks goes to Natasha, who discovered the bug and who has been working with me to debug it. Unfortunately, I don’t have an ETA for when the fix will be released, but it will be announced here as soon as it is.

I’m extremely happy to announce that Cryptnos 1.1 is now available for download, both for Windows and Android. Android users should be getting update notifications from the Android Market any time now. Windows users, of course, will be forced update manually… for now, at least. More on that in a bit.

I won’t rehash too many of the new bells and whistles, as that information has already been published to each platform’s respective page. However, there are a couple of big new items I’m rather happy about that I’d like to point out.

The big new feature is cross-platform exports. If you’ve been watching this site at all, you’ve probably seen my ramblings on how hard it is to get encryption to work on very different application frameworks. Well, we once again have the Legion of the Bouncy Castle to thank for making things a whole lot easier. Exports from Cryptnos for Windows 1.1 can now be imported into Cryptnos for Android 1.1 and vice versa. This means you can build your password parameters on one platform and copy them to another, keeping all your password data in sync. Note that you’ll need the new versions of both platforms in order for this new feature to work. Future versions on other platforms (Java, I’m thinking of you) should have this feature from the start. The old platform-specific export formats are still supported in a read-only mode, so your old backups should still be valid. However, the new export format is not backward compatible and going forward we will only export to the new format.

While Android users are notified of updates through the Android Market, Windows users have no such luck… until now. Cryptnos for Windows 1.1 now includes an update check that downloads a small XML file from this site about once a week. The check occurs in the background and will not interrupt your work flow. If no update can be found (or if an error occurs), the update check silently closes and you’ll never even know it was there. If an update is found, Cryptnos will ask if you’d like to download and install it. Not a good time? Just say no and Cryptnos will ask again in a week. Since Cryptnos is a security application, we feel that having the latest version is critical to the security of your password data. This will help fill a gap that we think is glaringly missing from the current Windows architecture.

There are a bunch of other little minor fixes and additions to both platforms; see each page for the full list. As always, if you have any problems or suggestions, feel free to e-mail us and let us know.

Following on the update to the previous post, now I should announce that work is under way on version 1.1 for both Android and Windows. Actually, I think 1.1 for Windows is close to finished, but I’m not ready to release it quite yet. I want to get started on 1.1 for Android, test them both thoroughly, and try to release them roughly around the same time.

The reason for the version bump and the simultaneous release is that there’s an important new feature I’ll be adding to both: cross-platform export files. Previously, both versions exported site parameters in platform-specific, incompatible formats. After doing a lot of research and experimentation, I think I’ve settled on a common format and encryption scheme that should let you export your sites on one platform and import them on another. Putting this in now also means that the pure Java version should get this feature in 1.0 rather than waiting until later. (Android uses Java as its primary language platform, and while there are lots of differences between Android Java and pure Java, this part should be pretty much identical, making porting it a piece of cake.)

Cryptnos for Windows 1.1 will also include a few minor enhancements, such as better feedback for invalid inputs and a few other minor UI tweaks. Clicking the Generate button will automatically copy the generated password to the system clipboard; this is a feature that already exists in Cryptnos for Android 1.0 and seemed like a no-brainer to add into the Windows version. I’m not sure what changes will be going into 1.1 for Android beside the cross-platform exports; I am, of course, open to suggestions for either platform.

How will this affect the recently announced start of Cryptnos for Java 1.0? Well, the coding has started, and the good news is that the cross-platform stuff should go in right away. I don’t expect a significant delay. Unfortunately, I don’t have an ETA for any of these releases yet, but I’ll post updates when anything interesting comes up.

One of the main goals I’ve always had for Cryptnos has been as much cross-platform compatibility as possible. As far as I can tell, so long as you always use the same text encoding on every platform, Cryptnos always generates the same password, regardless of whether you are using .NET, Android, or Java. That’s our core functionality right there, so needless to say I’m happy about this one.

However, as of this writing, there’s one place where cross-platform compatibility has eluded me: the import/export files. The raw data storage isn’t an issue; that almost has to be done in a platform dependent way. .NET uses the Windows registry, Android uses a database, and the Java version will likely use an encrypted text file. But I’ve always wanted to be able to export parameters from one platform and import them into another. That would have made the implementation and testing of the Android so much easier if I could have just imported the parameters I generated in .NET. Alas, this wasn’t the case, and I had to type every single one of them in and verify the results in both places. Currently, each platform exports their parameters in a different way, so you cannot import that data into a different platform.

For those who have never coded with encryption, it’s not a pretty place. It’s never as simple as “Here’s the plain text data, here’s the encryption key, and here’s the algorithm.  Put them all together and get the encrypted text.” You have to use the same key generation classes on every platform, or at least ones that are equivalent. You have to make sure your padding scheme is the same everywhere. If you get one little thing wrong, the data you encrypt on one platform won’t come out right on the other platform and you’ll get binary garbage. And of course, the API developers never make it easy for you, as the class and method names are never the same from one platform to another.

Fortunately, the problem is somewhat mitigated by the fact that Android uses Java as its primary development language. Thus, if I can find a way to encrypt something in Java that can be decrypted in .NET and vice versa, I’ll kill three birds with two stones. Sadly, that prize has eluded me so far, primarily for the reason mentioned above: .NET and Java name everything differently, and I have to figure out exactly what combination of options in both places will yield the same result.

Ideally, I want to use as many built-in classes as possible. If I can find a way to do what I want with the tools that are already built into each language, I keep the code size down and make it easier to port elsewhere. Failing that, however, I do have the fall-back of using the Legion of the Bouncy Castle Crypto API, which I’ve already dipped into for a few of our cryptographic hashes. I’d rather not use this option, however, as I’d like to keep the code base as small as possible, especially for the Android app. Adding additional library code that effectively duplicates functionality that already exists in the core library just makes the program bigger than it needs to be. That said, it does give me a common API that should be compatible between both .NET and Java.

If there is anyone out there who has experience coding cross-platform encryption between .NET and Java, especially using password-based AES, I’d love to hear from you. I’ve been doing research and found a few promising leads, but nothing has worked straight out of the box and it’s going to take a while to experiment and find out what’s not working.

UPDATE APRIL 28, 2010: Well, I think I answered my own question. I quickly discovered a number of important facts:

1. Trying to implement something as critically temperamental as encryption using to very different and very distinct APIs is not fun. .NET and Java do encryption in very different ways, and they don’t mesh well together. Similar sounding classes do things differently in each API, and things that end up do doing the same thing are usually named differently, making it hard to find a common ground. Thus, I’m ditching the totally native implementations and going with the Bouncy Castle API. It may make the applications larger, but at least they share the same API now and they work basically the same.
2. That said, using the “same” API ported to two different platforms doesn’t necessarily guarantee 100% compatibility. For example, I found one method on BC’s .NET code that was deprecated, only to find there was no comparable method like it in the Java API. Thus, I’m stuck using the deprecated .NET method to remain compatible with the Java method and hoping BC doesn’t break that in their next update. (Bad form there, BC.)
3. It helps to pay attention to which classes you use. There are a lot of similarly named classes, and it’s easy to get them confused. I kept on getting error after error, only to find out I was using two different classes, one on Java and a different one on .NET, at a critical point in the process. Seems like Programming 101, I know, but even old seasoned dogs like myself make boneheaded newbie mistakes every now and then.

And now, the point of the update: Thanks to this research and Bouncy Castle’s API, I have successfully encrypted data on Google Android and decrypted it with .NET, and vice versa. That was the most critical part of making cross-platform compatible export files work. So the call for help has been withdrawn, but thanks to anyone out there listening. (At least I hope all those requests to this site aren’t coming from my own IPs.) Look for future updates soon that result from this discovery.

I just wanted to make a quick post to announce that now that the .NET and Android versions are officially in the wild, I’ve started development on the Java version of Cryptnos. I’m not sure how long it will take to get to a usable beta. On one hand, I already have a good chunk of code written thanks to Android using Java as its development language. On the other hand, it’s literally been years since I’ve written a GUI Java application, so I’m having to refresh my memory while updating my knowledge on Java standards all at the same time.

You may be wondering why I’m even bothering with this. There is, after all, two versions of Cryptnos available now on two separate platforms. Why do another? Well, the .NET version was born out of necessity; I had an itch to scratch, so I wrote that first edition in the language I was using the most at the time, C#. Similarly, the Android version fulfilled a specific personal need; letting me use the same generated passwords on the go. While I originally used a PHP-based web service for that (which I eventually plan to release in some form as Cryptnos Online), that wasn’t always the best and most secure solution.

I want Cryptnos to be available to as many people as possible. .NET and Android can only go so far. While it’s technically possible to run .NET applications on other platforms using Mono, we have to face the fact that Mono is incomplete and not exactly trivial to install. Java is far more available and cross-platform, easily opening up our options for Macs, UNIX-derived systems, and beyond. And the online version, the forth piece to our puzzle, will cover just about everyone else who can’t run compiled code, such as other mobile platforms like iPhone OS, BlackBerry, and Symbian.

I’ll post updates as I have them in the Java news category for those who are interested.