More on Hashes

Since I last wrote about the problem with hashes, there has been a fair bit of activity and some progress:

  • An internet draft is available describing the nature of the attacks on hash functions, and how different internet applications are affected.
  • According to the OpenSSL changes file, additional hash algorithms are going to be supported in version 0.9.8. There is no indication of a date for that release, though.
  • Don Eastlake's internet draft on Additional XML Security Uniform Resource Identifiers (URIs) has progressed to its final status as RFC4051.

I have updated my previous article to reflect this.

[Updated 20051030 with latest URL for the Hoffman draft.]

SHA-1 and XMLDSIG: No Plan B?

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 RFC3275) 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 RFC4051.]
  • 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.

[Last updated 20050421: OpenSSL status, RFC4051.]

Neci Feihsi

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

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.

Netcraft Anti-Phishing Toolbar

Netcraft have released an anti-phishing toolbar. This sounded like a great idea right up to the point where I realised I couldn't use it because I don't use Internet Explorer.

That's right, this is at present something for those people who are (a) security conscious enough to read Netcraft's newsletters but (b) not security conscious enough to have heeded the warnings to stop using Internet Explorer.

Apparently, a Firefox version of the toolbar will be made available. Until then, this idea looks just a little cynical and pointless. They are really pleased with their TV coverage, though.


Schneier on Safe Personal Computing

Bruce Schneier is a well respected professional paranoid ("internationally renowned security technologist" is the way his web site puts it). He recently updated his list of tips for safe personal computing after a gap of a few years. Both old and new lists are full of sensible things you can do to make yourself more secure: if you do these things, you will be more safe. If you don't do these things, you should at least have a rationale ready.

This year's list is about 50% longer than the May 2001 version; I guess that doesn't surprise me, as the environment has taken several steps in the direction of "more evil" since then. For example, phishing for bank account information was relatively unknown "way back then". In the last year or so, this particular attack has grown by a factor of twelve (or more, depending on who you listen to) to the point where there are so many of these things in my inbox that it is sometimes hard to believe that anyone is taken in any more.

Having said which, the really interesting thing about the new list is that it is mainly the same as the old list. There are a couple of new things (buy a cheap NAT firewall box for home, don't ever use Internet Explorer) but most of the changes seem to be rewording, clarifications and more detail.

I would personally be very interested to see Bruce's own take on what he thinks has changed over the period. I'd also like to see him renew this list regularly. The only thing I worry about is that if the environment continues to get more hostile and nothing else improves, we are likely to need a list with just one entry: Trust No One.


Technical English: "Warhol Worm"

A recent article about the SoBig.F virus in the Economist magazine mentioned the idea of a so-called "Warhol Worm". I'd never heard this term before, so I went looking for the original use. Nicholas Weaver of UCB turns out to have coined this term to denote a worm that could infect every potential host in 15 minutes. This is of course a reference to Andy Warhol's quip that "In the future, everybody will have 15 minutes of fame".

If you read Weaver's article, though, you'll see that the important thing isn't how long a worm is famous for. Instead, he postulates (among other mechanisms) an author who quietly scans the internet for a particular vulnerability for some time, perhaps weeks or months, in order to build a list of susceptable machines. When the worm is released, these machines are used as the initial attack set. Combining a "hitlist" of 10,000 to 50,000 machines with other techniques, the result would be very fast infection of all potential machines, certainly far faster than security software vendors could possibly respond.

SoBig.F wasn't a Warhol Worm, and I don't know that we've seen one yet. The possibility that someone might use this "hitlist scanning" technique is just another reason to keep up to date with all those security patches, even for vulnerabilities for which no exploit is yet known.


Anti-security from Palm Europe

Security problems are usually built right into products and called "features". Sometimes, though, the vendor provides them free of charge as an after-market upgrade. This particularly egregious example comes from Palm Europe.



Subscribe to RSS - Security