Online FAQ

Last updated October 28th, 2010

In addition to the FAQs on this page, please read the FAQs on the main FAQ page, as they pertain to all platforms.

What is the purpose of Cryptnos Online?
Cryptnos Online serves several functions. First and foremost, is a showcase of the core functionality of the Cryptnos family of applications. It allows users to experiment with Cryptnos in a painless, no-commitment fashion first before taking the plunge to install the dedicated, platform-specific clients. You can play with the various parameters, see exactly what kind of passwords the program generates, and it gives you a pretty good idea of what to expect if you decide to install the full client.

In addition to this “test drive” mode, Cryptnos Online provides rudimentary support for platforms that do not currently have full Cryptnos clients. This allows desktops, laptops, netbooks, and various mobile devices that do not run Windows or cannot run Java to take advantage of Cryptnos’ core functionality. It also allows users who are dependent on the full clients to generate their passwords while away from their primary client, provided they remember all of their parameter data.

Does Cryptnos Online support saving my parameter data?
Unfortunately, no. We’ve toyed around with several ideas on how to accomplish this, but none of them make us very comfortable. Browser cookies can be sniffed, intercepted, and spoofed, and are not easily portable to multiple browsers. Heavier weight technologies such as Java or Flash are not ideal because they are unavailable on many platforms. Saving parameters to a database here on the Cryptnos server requires a great deal of trust on your part that we won’t compromise your data. While we’d like to think we’re trustworthy, we do not feel comfortable taking on that responsibility. So for the time being, Cryptnos Online won’t be able to save your parameters for you. We apologize for the inconvenience.
Cryptnos Online does not seem to support all the cryptographic hashes that the full clients support.
Unfortunately, this is correct. We have working JavaScript implementations of MD5, SHA-1, SHA-256, SHA-512, and RIPEMD-160. We do not have implementations of SHA-384, Whirlpool, or Tiger yet. We hope to add these sometime in the near future. Until then, if you use one of the other Cryptnos clients and rely on one of these missing hashes, you won’t be able to recreate those passwords with Cryptnos Online.
Why does Cryptnos Online require JavaScript?
We wanted to implement a clean, “trust no one” scenario. You shouldn’t have to hand over your parameter information to us to generate your password; that’s asking for a great deal of trust, and it’s not our place to really ask for that. Conversely, we take on a huge responsibility when we start handling your authentication information. If we were ever required by law enforcement or government authorities to hand over your parameter data, we would be forced to violate the trust you had placed in us. If we ever lost your data, you would be effectively locked out of your many accounts. This is a level of responsibility we don’t want to have.

By implementing Cryptnos in JavaScript, your parameter and password data never leaves your machine. Once you’ve downloaded our code, Cryptnos Online makes no further contact with our server. Your parameters are never sent to us, so we’ll never see them or your passwords. You must still trust that our code does what it says it does, but the source is readily available for you to review. Your threat vector is minimized, as is our responsibility for your data.

Of course, this also means we may potentially cut off users who cannot or will not execute JavaScript code. This was a known risk with this design, but it’s a decision we felt was worth the trouble based on the situations outlined above.

Why does Cryptnos Online issue a warning if I set the number of hash iterations higher than 500?
In our testing, we found that hash iteration values much higher than this resulted in significant performance issues on some platforms, causing pauses that made the app look non-responsive. This is also observable in Cryptnos Online, but to a lesser degree; JavaScript is inherently slow because it is interpreted, rather than compiled into machine code and directly executed. This is less of a problem for full client versions because the typical PC processor is much faster than, say, the processor in an Android mobile phone. However, on such devices this lag can make it seem that Cryptnos or the entire device has locked up, even though it is still hard at work. We ultimately decided that 500 iterations seemed a bit excessive. One iteration is usually enough, and anything more than ten is unlikely to be broken. So we stuck an upper limit on this rather than rewrite the password generation code. Rather than breaking the parameters for users on other platforms who may have more than 500 iterations in their saved settings, we put in a warning to let you know that these values may not be compatible with other platforms. If you rely on more than 500 iterations in Cryptnos Online and wish to make your parameters compatible with versions on other platforms, we recommend you step that back down so both platforms are the same.
Cryptnos Online does not work in browser x on platform y.
We’re sorry to hear that. As you can guess, there’s no way we can possibly test every browser and operating system combination out there. For one thing, we only have so much time in the day and this is a purely volunteer effort. For another, there are many platforms we don’t have access to for one reason or another. Thus, we try to test Cryptnos Online is as many browsers as we can, especially in the dominant browsers for a given platform. From there, we hope most of the others won’t be much different. (For example, hopefully testing Firefox on Windows will give us a good idea of how it will work on Linux or Mac OS.) If you encounter a bug, make sure to include your browser and OS versions when reporting it. Keep in mind that if you have a combination that we can’t test directly, we may ask for your help in debugging the issue.
Why doesn’t Cryptnos Online use HTTPS/SSL/TLS?
It’s on our to-do list, but we’re not in a position to implement it at the moment. For a bit of background, secure HTTP or HTTPS is an encrypted form of the HTTP protocol that uses either SSL (the older encrypted socket protocol) or TLS (its modern decedent) to encrypt HTTP traffic between the user and the server. HTTPS serves two main purposes: (1) to protect the conversation between the client and the server from eavesdropping and (2) to authenticate the server to the client, i.e. to prove to the client that the server is owned by the party they wish to communicate with.

With respect to the first item, encryption isn’t really necessary. Cryptnos Online is Open Source, so everyone can have access to the source code. Thus, it is not necessary to encrypt the page and accompanying code while it is being downloaded. Since all password generating activity takes place within your browser and no data is sent back to the server once the page is loaded, there is no need encrypt any returning traffic, because there is no returning traffic. Thus, encryption really is unnecessary.

However, authenticating the server is important so you can trust the code we send you really came from us and is unmodified. Thus, we do plan to implement HTTPS at some point. Unfortunately, technical and financial issues stand in our way. The Cryptnos site currently shares the same server as the GPF site, and only one SSL certificate can be installed at a time per server instance. If you attempted to access the Cryptnos site over HTTPS, you would get a certificate error stating that the domain of the certificate ( does not match the domain of the site (, which is true. In order for us to server Cryptnos over HTTPS, we’ll need a separate physical server, which is something we plan to implement eventually but which is financially challenging at the moment. We’re looking at our budget to see if we can afford a separate server now. If and when that becomes available, we’ll definitely pursue an SSL certificate so we can serve Cryptnos to you via HTTPS.

Another potential option we are exploring is to mirror the Cryptnos Online code directories on the GPF site (i.e. you could access the code via the domain) and use GPF’s existing certificate. This is certainly more economical, but it may be confusing for users to come to and be mysteriously bounced to These fears may be unwarranted, of course, so feedback concerning this option is certainly welcome.

The passwords generated by Cryptnos Online don’t match those created by the full clients even though I know I have my parameters correct!
This is an issue related to this news item. The most likely scenario is that the platform(s) you are running the full client on does not use UTF-8 as the default character encoding. Before versions 1.2.x on all platforms, Cryptnos used the system default character encoding for password generation and could not be configured otherwise. Sometimes this isn’t a problem; for example, UTF-8, US-ASCII, Windows-1252, and several other character sets contain a lot of overlap and actually encode many characters the same way. You may be using different character sets on several platforms and never know it.┬áCryptnos Online, however, only uses UTF-8. If the platform you are running the full client uses an encoding incompatible with UTF-8, it will generate different passwords than Cryptnos Online, even using an identical set of parameters.

The solution is to upgrade to Cryptnos 1.2.x or higher on the other platforms as soon as it becomes available. Version 1.2.x introduces an Advanced Settings feature that will let you configure which character encoding to use for password generation. If you plan to use Cryptnos Online, you will need to configure your other clients to use UTF-8. If you do not plan to use Cryptnos Online, the character encoding doesn’t matter as much so long as all clients use the same encoding. Note that changing this sitting may “break” existing passwords if the old and new encoding settings do not sufficiently overlap.

If this does not fix the problem, please contact us so we can file a bug report.