February 2005

People in the know are reporting that the 160-bit Secure Hash Algorithm has been broken by a group in China. When the group’s paper is published we’ll all be able to judge, but the initial reports indicate that SHA-1 has about 11 bits worth (2000 times) less collision resistance than its output length would suggest. This isn’t a huge surprise; there were some indications last year that this might happen eventually although I don’t think anyone expected things to move so quickly.

The break is a big deal for academic cryptographers, but it doesn’t seem to represent an immediate disaster in practice. Existing digital signatures and certificates are probably safe for now, in particular, as the kind of attacks you can mount against a system using collisions mainly apply to new signatures. The revised 69-bit strength of SHA-1 is still good today against all but fairly wealthy adversaries; Bruce Schneier has some estimates of how rich.

Obviously, there will now be a move towards beefier hash algorithms like SHA-256 or SHA-512 (PDF link). In the long run, because these come from the same family they may turn out to give only temporary respite. More immediately, they aren’t implemented by all current cryptographic libraries: for example, they have been in Java since 1.4 but the extremely popular OpenSSL package doesn’t ship with support for them yet.

Further up the stack, many standards already allow for selectable algorithms and for negotiated selection of them at run time. That’s harder to do with digital signature applications, because in this kind of context there isn’t normally a way to negotiate algorithms. This means, for example, that public suppliers of digital certificates probably won’t be able to shift from SHA-1 very soon, as many of the systems that use their certificates (browsers, for example) are based on cryptographic libraries that don’t support anything stronger than SHA-1 today.

One place where there seems to be a complete absence of a “Plan B” at present is the joint IETF/W3C standard for digital signatures in XML (XMLDSIG). The published standard from 2002 (also RFC 3275) only discusses SHA-1. Moving away from this position requires several steps:

• Implementation of additional algorithms in the basic cryptographic libraries such as OpenSSL (already true for some libraries, OpenSSL has code checked in but not released). [20050421: OpenSSL change log indicates this is scheduled for the 0.9.8 release.]
• A specification of URIs naming additional algorithms for XMLDSIG (Don Eastlake has an Internet Draft on this dating from last year.) [20050421: this is now RFC 4051.]
• Access to those algorithms from XMLDSIG implementations, such as Apache XML Security.
• Either:
  • Some sort of standard specifying that XMLDSIG implementations should implement additional algorithms, or
  • A similar kind of must-implement agreement even higher in the stack, in my area of interest either at the level of SAML or Shibboleth.
• Last but not least: everyone installs new versions of all of the above.

None of this sounds like it is going to happen overnight. It is important that it all happens some time soon, though, as the general feeling seems to be that it is likely that further progress will be made against SHA-1; it is just the timing that is unknown.

I got an interesting phish in today’s e-mail. Here’s how it looked in Thunderbird:

Dera Baalcrys Membre,

Tsih eamil was setn by the Braclays svreer
to verify yoru eiaml addrsse.

…and so on. My initial fears that the bad guys have finally lost it and just given up were allayed when I looked at the actual source of the message:

Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
…
De‮ra‬ Ba‮alcr‬ys
Memb‮re‬,

What is going on here? The message body is an attempt at Unicode. Code point 8238 is “right-to-left override”; code point 8236 is “pop directional formatting”. The sections contained within the “‮…‬” groups are therefore supposed to be printed backwards.

How delightfully creative. Except that the message is marked as being encoded in ISO-8859-1, which doesn’t contain those code points. All the cleverness (probably aimed at some mail program that accepts the invalid code points) was ignored, leaving gibberish. The good news is that even if they fix that, the presence of “‮” in e-mail is going to be a pretty good indicator of something phishy going on.

Hiring good people is hard. If you advertise, you face wading through dozens or hundreds of CVs trying to figure out who the best people are. If you filter CVs, then filter again through interviews, you’re probably inclined to think that you’re being terribly selective, and that your final hires are among an elite. People often say “we hire the top 1%”.

There are several fallacies there: most obviously, it is hard to pick the people to interview on the basis of a CV, and interviewing people is a pretty hit-and-miss affair. More crucially, and less well recognised, is that you only get to pick from the people who apply, not from the whole population. Joel Spolsky’s recent article does a great job of explaining this in a really clear way.

One of Joel’s conclusions, which matches at least one case in my own experience, is that working with summer students (US: interns) is a good idea. This is not for the usually stated reasons (they work for peanuts! they know all the latest research! they are really gullible about working conditions!) but simply because if someone turns out to be really good, a summer work placement might be almost the last chance anyone has to hire them before they fall off the hiring radar for good.

Comments are back after an outage of a week or so. Originally I took them off-line because of a mail relay vulnerability discovered in Movable Type. They didn’t get turned back on once I had installed Movable Type V3.15 because I forgot to change the mode on the new version of the comments script. D’oh!