I'm pleased to announce that the nightly Firefox 3 builds now contain the Camellia cipher. The Camellia cipher was developed by researchers at NTT and Mitsubishi Electric Corporation. We expect that Camellia will be big in Japan in the coming years, and when Firefox 3 is released it will be ready to go. (At this point only developers and testers should be running Firefox 3 builds.)

We don't normally add new encryption technologies to Firefox, so this addition is rather special. In the encryption world, new is bad. Older is better. Ciphers that have been reviewed, deployed, and attacked repeatedly (and survived!) are best. To give you an idea of how rarely we add ciphers, the last symmetric cipher we added was AES in 2002.

Camellia also represents a great open source partnership. The Camellia team went to great lengths to publish their technology and to seek reviews. They provide royalty-free licenses to their patents. They worked through the IETF process to create RFCs for the TLS, IPSec, and CMS protocols. They wrote code to implement the cipher. They contributed this code to the NSS crypto libraries under the standard Mozilla tri-license. We were then able to incorporate Camellia into NSS, and then activate it in Firefox. That process took them years of hard work and diplomacy.

I am very impressed at how well the Camellia team was able to work through all these matters leading up to today's announcement. They have been a pleasure to work with! I look forward to more Firefox uptake in Japan as a result.

If you are running the nightly Firefox 3 builds, you can visit the Camellia test server and check the cipher you negotiated (Page Info): https://info.isl.ntt.co.jp/crypt/eng/camellia/index.html

Here is the bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=382223

Here is the Wikipedia article: http://en.wikipedia.org/wiki/Camellia_(cipher)

I recently obtained an original manual for the M-325 converter, an American encryption machine used between 1944 and 1946.

There isn't a lot of information about the M-325 compared to more famous machines like the Enigma. Part of the reason may be that the machine did not work well in the field. It looks positively fragile.

I transcribed and scanned the manual, and posted it here. I've only seen the M-325 in person at the National Cryptologic Museum.  Speaking of which if you have not been there and like this sort of thing, it's worth the trip.

The Wikipedia article on the M-325 has a little information, and Jerry Proc's page has some additional photos.

If you have additional information on this device, drop me a line.

The times are changing for the cryptography in your browser.

As many of you know, the SSL2 protocol has been superseded by the SSL3 protocol, and the TLS 1.0 and 1.1 protocols. As a result, we're working to remove the SSL2 protocol from the Mozilla clients. We'll be able to send the SSL3 hello message to the server when starting an SSL connection. The SSL3 hello will allow us to support a new type of cryptography, called Elliptic Curve Cryptography (ECC). It will also allow us to support Server Name Indication (SNI). [See this page for more information.]

Also, a number of ciphersuites with short (weak) key lengths (40-bits and 56-bits) have fallen out of vogue. They are just too weak to be trusted. So we're working to turn them off as well.

Microsoft is working on the same goals. Here is one of their blogs:
http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx

Here is the page we're using to track the few remaining SSL2-only sites that matter:
http://wiki.mozilla.org/Necko:SSL_v2_Sites

And here is Gerv's blog on the same subject:
http://weblogs.mozillazine.org/gerv/archives/2005/09/ssl2_must_die.html

If you run a web site that uses only SSL2, or one that only uses weak ciphers, it's time for you to upgrade your site!

As an aside, we're continuing to work on "mod_nss", an Apache web server module that allows administrators to use the NSS crypto libraries rather than OpenSSL. See here for more information:
http://directory.fedora.redhat.com/wiki/Mod_nss

I've been poking around various web sites and have noticed that major on-line services often fail to use SSL to protect their login pages. I'm not talking about sites where they don't need, or don't care enough to use SSL. I'm referring to major sites that use SSL, but only after you hit the Submit button. From a password security standpoint, this is sufficient. You don't actually need to protect the page that says "Type in your user name and password". It does not matter if hackers see that page, as long as they cannot see your name and password when you submit it. At least it didn't used to matter.

The problem today is that phishing has added some complexity to the security analysis of this situation. When phishers send out emails, they tell the victims that there's been some sort of problem, and they need to login to the web site to clear things up. They provide a link in the email which would normally take the victims to the real web site, but in the case of these attacks, they take the victim to a web site that is under the control of the phishers. These phishing emails and web sites are getting very good. It may not be possible to tell just by looking at the web page itself if it's your bank's web site, or the phisher's.

Why does this attack work?

In the early days of Netscape, we spent a lot of time and energy to train the press and customers that they should never type any personal information into the browser unless they saw the lock icon. Long before the word "phishing" was coined, we knew bad people might do something which would be thwarted if users followed this advice. And it worked for quite some time. In fact, we had usability testing which showed that this training worked.

Sadly, things have changed. Many major companies have implemented their web sites so as to undo this user training. Users now have no way of knowing what's real and what's not real because their banks, travel agencies, and merchants have taught them through repeated experience that it's OK to type their account information and passwords into pages where there is no lock icon. And because in most cases, nothing bad happens, people got used to it.

It's really disturbing that so many of the biggest sites with the biggest brand names fail to put SSL on their login pages. In many ways, they have unwittingly created the environment that allows phishers to thrive.

In my next few posts, I'll explore the banking situation, some myths around SSL, and some best practices I'd like to see all financial institutions follow.

Here's a little crypto news that's been on my mind lately.

The NSS crypto libraries, the first FIPS-validated open-source crypto implementation, is now well on it's way to completing it's 4rd round of FIPS 140 (Level 2) validation. On 1/20/2006 we received the certificates from NIST for AES, Triple DES, SHS, and HMAC.

This is an important milestone. We'll use the FIPS version of NSS in upcoming versions of Red Hat products like the Directory Server and Certificate System. We will also use these libraries in upcoming versions of Firefox and Thunderbird, allowing people in the U.S. Government to upgrade from older versions of the Netscape products (like Netscape Communictor 4.7 in some cases!).

I went through some old docs a few days ago, and was reminded that NSS received its first validation in 1997 as part of the Netscape products. In 2001 we open sourced NSS (after the U.S. export regs changes and the RSA patent expired). In that same year NSS also received its second round of FIPS 140 Level 2 validation, the first as an open source product.

If you've read this far, these links might interest you:
http://wiki.mozilla.org/FIPS_Validation
http://www.mozilla.org/projects/security/pki/nss/fips/
http://www.mozilla.org/projects/security/pki/nss/overview.html

The Russian Fialka (which means "violet" like the color or the flower) was an encryption machine used by the Soviet Union and Russia up until about 1990. Very little is known about them, but a few are making their way out of Eastern Block countries. They are similar to the more famous Enigma machines, but have better security, paper tape output, and a number of other improvements. On the downside, they are heavy (around 50lbs) and the power supply is in another box (which is also heavy).

The Fialka uses 11/16" paper tape rolls, which I just found on an Ebay store (one man's junk...), and should have in a week or two. Now I just need to get some custom power cables to connect the power supply to the Fialka. The plugs are completely foreign to me, but I'm hoping they're a European standard size.

I got the Fialka running around 1am last night. I spent a fair amount of time
with a volt-meter making sure I got the voltage and polarity right.Unlike the Enigma, the Fialka has some electronic parts, which means a smokey death was quite possible. Although the power converter is well labeled, my Russian is a bit rusty so lots of double-checking felt like a worthwhile expense.

It's not as loud as I thought it was going to be, but it's not quiet either. It sounds like one of the old IBM selectric typewriters when I fired it up, and also when I typed on it.

I was able to encrypt a message, and then to decrypt it. The best part was that it spits out paper tape with text and holes punched. Why would you need to have the encoded messages punched into the paper if the text was also there? To be able to feed it into another machine and automatically decrypted, of course! The machine has a paper tape reader on the front. I was able to feed the encrypted message back into the machine, and it spit out the original text. It's quite sophisticated, actually. You can see pictures of the paper tape here at the bottom: http://www.ilord.com/fialka.html

I was also able to find several old spools of teletype paper tape on Ebay which I was able to get mounted onto the Fialka paper tape feeder. Now all I need is some old teletype-style print ribbons and I'll be in Russian encryption heaven for at least another few months.