Everybody knows that MD5 is as terribly useless as ROT13 and you should have switched to SHA3-512 like twenty years ago. But lots of usage sticks around, and will continue to stick around for a long time to come, leading to the long tail of MD5. Why not simply convert to a better hash function? Maybe it’s not so simple.

TCP ISN

Long ago, people started to realize that tcp_iss += 65536 wasn’t as unpredictable as previously thought. (Around the same time, they also started to realize that rlogin wasn’t as secure as previously thought.) Pure random ISNs would be awesome, but they have a tendency to repeat, causing spurious connection failures when new ISNs land in the window of old connections. What’s needed is a per {srchost:port:dsthost:port} tuple counter that increments at 64k. That would require a lot of counters, however; enter RFC 1948 Defending Against Sequence Number Attacks. There’s a single global counter that increments, but it’s randomly offset by hashing the tuple.

What does RFC 1948 say about choice of hashing algorithm? “MD5 is a good choice.” And that’s what everybody used. In 2010, RFC 1948 was obsoleted by RFC 6528. RFC 6528 revised the algorithm recommendation to “MD5 would be a good choice.” It goes on to explain the rationale.

Convertible? Yes. OpenBSD uses SHA512 now instead. Necessary? Probably not, but if you don’t want MD5 to show up in code greps, something to change. Since ISNs are by definition “secret” there are no interoperability concerns with changing algorithm.

TCP MD5

Another place MD5 is used in TCP is to protect your BGP sessions from mudge. RFC 2385 introduced MD5 signatures to authenticate packets. It was later obsoleted by RFC 5925 which defines more options, but in practice migration has been slow. There’s some code in a branch of FreeBSD, for example, but not in mainline.

Convertible? Hard. Can only replace MD5 if all peers also replace it.

Another choice is IPsec, but in the places where MD5 signatures are used, they’re being used because IPsec isn’t viable.

MD5 AUTH

MD5 finds use in a few authentication protocols. One is CRAM-MD5 described in RFC 2195 for POP and IMAP. A few updates include RFC 2831 and RFC 2617 for HTTP.

One of the cool things about MD5 auth is that it is a kind of (not quite provably secure) zero knowledge proof that the user knows the password. The protocol was designed back when everything was plaintext. There was some sense to providing plaintext access to a POP mailbox because the SMTP connections were also all plaintext. The only “secret” was the user’s password. Sending the MD5 of the password and a challenge nonce prevented eavesdroppers from learning the password. It also, however, prevented the server from learning the password. OK, so that’s not very interesting considering that the protocol only works if the server already has the plaintext. But you’ll never accidentally transmit your password to an imposter server, unlike most of the TLS wrapped send the password to the server protocols that replaced it.

Convertible? Not really. Deletable? Yes. Pretty much all uses of MD5 auth have been replaced by TLS connections now. It’s a relic. There’s no need to update or change it to SHA512 or anything better.

From time to time people try to breathe new life into this idea with assorted client side bcrypt proposals. But without going to a lot of work (more work than I’ve ever seen anyone do), that adds a lot less security than one thinks.

Content-MD5

Another HTTP use is the Content-MD5 header from RFC 1864. Has anybody proposed a Content-SHA512 replacement? There is RFC 3230 Instance Digests in HTTP which brings to the table not just SHA1 but also 16-bit UNIX “sum”, though one could extend it ad hoc. A little rare in the wild, however.

Convertible? Better replaced by HTTPS for transport integrity, but for the purposes Content-MD5 remains in use (download verification, something TLS doesn’t guarantee) it seems it’s here to stay.

md5crypt

MD5 is of course also the algorithm behind md5crypt. This still sees life in .htpasswd files and such. It wouldn’t be so bad if the cost factor could be adjusted, but md5crypt unfortunately hard coded 1000 rounds, limiting its useful lifespan. Most systems support a flexible crypt interface these days, but various tooling instead standardized on the apr1 spelling.

Convertible? Ugh. Migratable? HTTP auth may never die, but handling authentication at the application layer brings its own benefits.

checksums

MD5 also landed in a few other places for non cryptographics purposes. For example, OpenBSD softraid checksums its ondisk metadata with MD5. Migrating away would require rewriting everybody’s disk to little benefit. Maybe some day I’ll get on this, but it’s a low priority.