RFC 4270

Attacks on Cryptographic Hashes in Internet Protocols ✨

📜 RFC 4270 💖 Network Working Group, November 2005

👩‍💻 Authors: P. Hoffman (VPN Consortium) and B. Schneier (Counterpane Internet Security)

🎀 Category: Informational, so this one is info only, not a standard 🌸

Status of This Memo 📝

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice ©️

Copyright (C) The Internet Society (2005).

Abstract 🦋

okay so recently people announced some better-than-expected collision attacks on popular hash algorithms, and now everyone's asking whether common Internet protocols need to change, and if so, how 😭. This document sums up how hashes get used across lots of protocols, talks about how the collision attacks do and don't affect those protocols, shows how to thwart known attacks on digital certificates, and covers future directions for protocol designers 🧚.

1. Introduction 💅

so in summer 2004, a team of researchers showed real evidence that the MD5 hash algorithm was susceptible to collision attacks [MD5-attack] 😳. Then in early 2005, that same team demonstrated a similar attack on a variant of the SHA-1 [RFC3174] hash algorithm, and they predicted that the normally used SHA-1 would also be susceptible with a large amount of work (but at a level below what should be required if SHA-1 worked properly) [SHA-1-attack] 🙈. Also in early 2005, researchers showed a specific construction of PKIX certificates [RFC3280] that use MD5 for signing [PKIX-MD5-construction], and another researcher found a faster method for finding MD5 collisions (eight hours on a 1.6-GHz computer) [MD5-faster] 🔥.

Because of these announcements, there has been a great deal of discussion by cryptography experts, protocol designers, and other concerned people about what, if anything, should be done based on the news 🗣️. Unfortunately, some of these discussions have been based on erroneous interpretations of both the news and how hash algorithms are used in common Internet protocols 💀.

Hash algorithms are used by cryptographers in a variety of security protocols, for a variety of purposes, at all levels of the Internet protocol stack 🌈. They're used because they have two security properties: to be one way and collision free. (There is more about these properties in the next section; they're easier to explain in terms of breaking them 🫶.) The recent attacks have demonstrated that one of those security properties is not true. While it is certainly possible, and at a first glance even probable, that the broken security property will not affect the overall security of many specific Internet protocols, the conservative security approach is to change hash algorithms 🛡️. The Internet protocol community needs to migrate in an orderly manner away from SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms ✨.

This document summarizes what is currently known about hash algorithms and the Internet protocols that use them. It also gives advice on how to avoid the currently known problems with MD5 and SHA-1, and what to consider if predicted attacks become real 🍓.

A high-level summary of the current situation is:

• Both MD5 and SHA-1 have newly found attacks against them, the attacks against MD5 being much more severe than the attacks against SHA-1 💔.
• The attacks against MD5 are practical on any modern computer 😱.
• The attacks against SHA-1 are not feasible with today's computers, but will be if the attacks are improved or Moore's Law continues to make computing power cheaper 📉.
• Many common Internet protocols use hashes in ways that are unaffected by these attacks 🙌.
• Most of the affected protocols use digital signatures ✍️.
• Better hash algorithms will reduce the susceptibility of these attacks to an acceptable level for all users 💜.

---

2. Hash Algorithms and Attacks on Them 🔐

A "perfect" hash algorithm has a few basic properties. The algorithm converts a chunk of data (normally, a message) of any size into a fixed-size result. The length of the result is called the "hash length" and is often denoted as "L"; the result of applying the hash algorithm on a particular chunk of data is called the "hash value" for that data. Any two different messages of any size should have an exceedingly small probability of having the same hash value, regardless of how similar or different the messages are 🪄.

This description leads to two mathematical results. Finding a pair of messages M1 and M2 that have the same hash value takes 2^(L/2) attempts. For any reasonable hash length, this is an impossible problem to solve (collision free). Also, given a message M1, finding any other message M2 that has the same hash value as M1 takes 2^L attempts. This is an even harder problem to solve (one way) 🧠.

Note that this is the description of a perfect hash algorithm; if the algorithm is less than perfect, an attacker can expend less than the full amount of effort to find two messages with the same hash value 👀.

There are two categories of attacks.

Attacks against the "collision-free" property:

• A "collision attack" allows an attacker to find two messages M1 and M2 that have the same hash value in fewer than 2^(L/2) attempts 💥.

Attacks against the "one-way" property:

• A "first-preimage attack" allows an attacker who knows a desired hash value to find a message that results in that value in fewer than 2^L attempts 🕵️.
• A "second-preimage attack" allows an attacker who has a desired message M1 to find another message M2 that has the same hash value in fewer than 2^L attempts 🕵️‍♀️.

The two preimage attacks are very similar. In a first-preimage attack, you know a hash value but not the message that created it, and you want to discover any message with the known hash value; in the second-preimage attack, you have a message and you want to find a second message that has the same hash. Attacks that can find one type of preimage can often find the other as well 🔁.

When analyzing the use of hash algorithms in protocols, it is important to differentiate which of the two properties of hashes are important, particularly now that the collision-free property is becoming weaker for currently popular hash algorithms 🧐. It is certainly important to determine which parties select the material being hashed. Further, as shown by some of the early work, particularly [PKIX-MD5-construction], it is also important to consider which party can predict the material at the beginning of the hashed object 🔮.

2.1. Currently Known Attacks 🎯

All the currently known practical or almost-practical attacks on MD5 and SHA-1 are collision attacks. This is fortunate: significant first- and second-preimage attacks on a hash algorithm would be much more devastating in the real world than collision attacks, as described later in this document 😮‍💨.

It is also important to note that the current collision attacks require at least one of the two messages to have a fair amount of structure in the bits of the message. This means that finding two messages that both have the same hash value and are useful in a real-world attack is more difficult than just finding two messages with the same hash value 🧩.

3. How Internet Protocols Use Hash Algorithms 🌐

Hash algorithms are used in many ways on the Internet. Most protocols that use hash algorithms do so in a way that makes them immune to harm from collision attacks. This is not by accident: good protocol designers develop their protocols to withstand as many future changes in the underlying cryptography as possible, including attacks on the cryptographic algorithms themselves 👑.

Uses for hash algorithms include:

• Non-repudiable digital signatures on messages. Non-repudiation is a security service that provides protection against false denial of involvement in a communication. S/MIME and OpenPGP allow mail senders to sign the contents of a message they create, and the recipient of that message can verify whether or not the signature is actually associated with the message. A message is used for non-repudiation if the message is signed and the recipient of the message can later use the signature to prove that the signer indeed created the message 📧.
• Digital signatures in certificates from trusted third parties. Although this is similar to "digital signatures on messages", certificates themselves are used in many other protocols for authentication and key management 🪪.
• Challenge-response protocols. These protocols combine a public large random number with a value to help hide the value when being sent over unencrypted channels 🎲.
• Message authentication with shared secrets. These are similar to challenge-response protocols, except that instead of using public values, the message is combined with a shared secret before hashing 🤫.
• Key derivation functions. These functions make repeated use of hash algorithms to mix data into a random string for use in one or more keys for a cryptographic protocol 🗝️.
• Mixing functions. These functions also make repeated use of hash algorithms to mix data into random strings, for uses other than cryptographic keys 🌀.
• Integrity protection. It is common to compare a hash value that is received out-of-band for a file with the hash value of the file after it is received over an unsecured protocol such as FTP 📁.

Of the above methods, only the first two are affected by collision attacks, and even then, only in limited circumstances. So far, it is believed that, in general, challenge-response protocols are not susceptible, because the sender is authenticating a secret already stored by the recipient. In message authentication with shared secrets, the fact that the secret is known to both parties is also believed to prevent any sensible attack. All key derivation functions in IETF protocols take random input from both parties, so the attacker has no way of structuring the hashed message 🥹.

4. Hash Collision Attacks and Non-Repudiation of Digital Signatures ✨

okay so the basic vibe of a collision attack on a hash algorithm inside a digital-signature protocol is that the attacker makes two messages that share the same hash value, gets one of them signed, and then reuses that signature on the other message for some shady purpose 🙈. Exactly what goes down depends on the protocol and on what the victim does when they see the signed message 💅.

The iconic example is two messages: one says "I will pay $10 for doing this job" and the other says "I will pay $10,000 for doing this job" 💀. You show the first one to the victim, get them to sign it, do the job, swap in the second message under the signed authorization, present the altered signed message (its signature still checks out, periodt), and demand the bigger payout 🤑. If the victim says no, you drag them to court and flash the second signed message 😤.

Most non-repudiation attacks need a human to look at the signed message and decide whether it's legit. With a hash-collision attack, the sketchy message's signature is valid, but so is the signature on the original message 👀. The victim can pull out the original message, show they signed it, and show that the two hash values match. The odds of that happening by accident are one in 2^L, which is basically zero for either MD5 or SHA-1 🧮.

So, to stop a hash collision attack in a non-repudiation protocol where a human is relying on the signed message as authorization, the signer needs to keep a copy of the original message they signed 📝. Messages that share a hash with other messages have to be made by the same person, and they don't happen by accident under any known likely circumstances 🙅‍♀️. That the two messages have the same hash should cause enough doubt in the judge's mind to make the legal attack fall apart (and maybe get the attacker charged with intentional fraud) ⚖️.

Stopping hash collision attacks in automated non-repudiation protocols is potentially harder, because there might be no humans paying close enough attention to argue about what should have happened 🤖. In electronic data interchange (EDI) applications, for example, actions are usually taken automatically once a signed message is authenticated. Figuring out the practical effects of hash collisions would take a detailed look at the protocol 🔍.

5. Hash Collision Attacks and Digital Certificates from Trusted Third Parties 🎀

Digital certificates are a special case of digital signatures ✨. Generally there's no non-repudiation attack on trusted third parties, because certificates have a specific format 💖. Digital certificates show up all the time in Internet protocols for key management and for authenticating the party you're talking to, maybe before granting access to network services or trusting them with private data like credit card info 💳.

So it really matters that the party granting access can trust that the certificate correctly identifies the person or system it names 🫶. If an attacker can get a certificate for two different identities using just one public key, the victim can be tricked into thinking one person is someone else 😭.

The collision attack on PKIX certificates described in early 2005 relied on the attacker being able to make two different public keys that give the body of the certificate the same hash value 🧠. For this to work, the attacker has to be able to predict the contents and structure of the certificate before it's issued, including the identity that will be used, the serial number that goes in the certificate, and the start and stop dates of its validity period 📅.

The end result is that one person with a single identity can get a digital certificate over one public key, but then pretend it was over a different public key (with the same identity, valid dates, and so on) 🎭. Since the identity is the same in both certificates, there are probably no real-world examples where this attack would give the attacker any advantage 🤷‍♀️. At best, someone could claim the trusted third party made a mistake by issuing a certificate with the same identity and serial number for two different public keys. Honestly? That's pretty far-fetched 🙄.

Super important note: collision attacks only touch the parts of certificates that have no human-readable information, like the public keys 🔑. An attack that takes a certificate with one human-readable identity and makes it useful for a second human-readable identity would need way more effort than a simple collision attack 💪.

5.1. Reducing the Likelihood of Hash-Based Attacks on PKIX Certificates 🛡️

If a trusted third party that issues PKIX certificates wants to dodge the attack described above, they can block it by making the other signed parts of the certificate random enough that the attacker gets no advantage 🎲. Ideas that have been suggested include:

• making part of the certificate serial number unpredictable to the attacker 🔢
• adding a randomly chosen component to the identity 🎲
• making the validity dates unpredictable to the attacker by skewing each one forwards or backwards ⏩⏪

Any of these mechanisms would make the attacker do a lot more work to trick the issuer into generating a certificate that's vulnerable to the attack 😤.

6. Future Attacks and Their Effects 🔮

Okay, the security community is split on what to do now 😬. Even the two authors of this document don't agree on what to do now 🙃.

One of us (Bruce) thinks everyone should start migrating to SHA-256 [SHA-256] right now, because of the weaknesses already demonstrated in both MD5 and SHA-1 🚨. There's an old saying inside the US National Security Agency (NSA): "Attacks always get better; they never get worse." 💀 The current collision attacks against MD5 are easy to pull off on a single computer 💻. The collision attacks against SHA-1 are at the far edge of feasibility today, but they'll only get better with time 📈. It's better to migrate to the new hash standard before there's a panic, not after 🏃‍♀️. Just as everyone moved from SHA-0 to SHA-1 because of some unknown vulnerability found inside the NSA, we need to move from SHA-1 to SHA-256 based on these most recent attacks 🔄. SHA-256 has a 256-bit hash length, which gives us a much bigger security margin if new attacks turn up 🛡️. Meanwhile, more research in the cryptographic community over the next several years should lead to further improvements in hash algorithm design, and maybe an even more secure hash algorithm 🧪.

The other of us (Paul) thinks this might not be wise, for two reasons 🤔. First, the collision attacks on current protocols haven't been shown to have any noticeable real-world effects 🙅‍♀️. Second, it isn't clear yet which stronger hash algorithm will be a good long-term choice 🌫️. Switching from one algorithm to another leads to inevitable interoperability problems and confusion for typical crypto users 😵‍💫. (Of course, if any practical attacks are found before the community agrees on the properties of the cipher-based hash algorithms, Paul would switch to "move to SHA-256 now" 🔀.)

Both authors agree that work should be done so all Internet protocols can use different hash algorithms with longer hash values 🙌. Luckily, most protocols today already can do this, and the ones that can't should get fixed soon 🛠️.

The authors feel similarly about new protocols being developed: Bruce thinks they should start using SHA-256 from the start, and Paul thinks they should use SHA-1 as long as the new protocols aren't susceptible to collision attacks 🧩. Any new protocol must be able to change all of its cryptographic algorithms, not just its hash algorithm 🔁.

7. Security Considerations 🔐

The entire document is about security on the Internet 🌐.

The discussion here assumes that the only attacks on hash algorithms used in Internet protocols are collision attacks 🎯. Some significant preimaging attacks have already been found [Preimaging-attack], but they aren't practical yet 😮. If a practical preimaging attack is discovered, it would drastically affect many Internet protocols 🚨. Here, "practical" means an attacker could execute it in a meaningful amount of time for a meaningful amount of money 💸. A preimaging attack that costs trillions of dollars and takes decades to preimage one desired hash value or one message is not practical 🙅‍♀️. But one that costs a few thousand dollars and takes a few weeks might be very practical 😱💀.

8. Informative References 📚

[MD5-attack]            X. Wang, D. Feng, X. Lai, and H. Yu,
                        "Collisions for Hash Functions MD4, MD5,
                        HAVAL-128 and RIPEMD", August 2004,
                        <http://eprint.iacr.org/2004/199>.

[MD5-faster]            Vlastimil Klima, "Finding MD5 Collisions - a
                        Toy For a Notebook", March 2005,
                        <http://cryptography.hyperlink.cz/
                        md5/MD5_collisions.pdf>.

[PKIX-MD5-construction] Arjen Lenstra and Benne de Weger, "On the
                        possibility of constructing meaningful hash
                        collisions for public keys", February 2005,
                        <http://www.win.tue.nl/~bdeweger/
                        CollidingCertificates/ddl-final.pdf>.

[Preimaging-attack]     John Kelsey and Bruce Schneier, "Second
                        Preimages on n-bit Hash Functions for Much
                        Less than 2^n Work", November 2004,
                        <http://eprint.iacr.org/2004/304>.

[RFC3174]               Eastlake, D. and P. Jones, "US Secure Hash
                        Algorithm 1 (SHA1)", RFC 3174,
                        September 2001.

[RFC3280]               Housley, R., Polk, W., Ford, W., and D. Solo,
                        "Internet X.509 Public Key Infrastructure
                        Certificate and Certificate Revocation List
                        (CRL) Profile", RFC 3280, April 2002.

[SHA-1-attack]          Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu,
                        "Collision Search Attacks on SHA1",
                        February 2005,
                        <http://theory.csail.mit.edu/~yiqun/shanote.pdf>.

[SHA-256]               NIST, "Federal Information Processing
                        Standards Publication (FIPS PUB) 180-2,
                        Secure Hash Standard", August 2002.

Appendix A. Acknowledgements 🫶

The authors want to thank the IETF community, especially folks active on the SAAG mailing list, for their input 💜. We'd also like to thank Eric Rescorla for early material that went into the first version 🌸, and Arjen Lenstra and Benne de Weger for significant comments on the first version of this document 🧚.

Authors' Addresses 🎀

okay bestie, the authors are Paul Hoffman from the VPN Consortium, reachable at paul.hoffman@vpnc.org 💌

and Bruce Schneier from Counterpane Internet Security, at schneier@counterpane.com 🔐

Full Copyright Statement 💅

the copyright belongs to The Internet Society (2005) 🌸

the authors keep all their rights, except for whatever is set out in BCP 78 🦋

and the whole document is basically handed over on an "AS IS" basis. ngl this part is a legal disclaimer, so here's the gist: THE CONTRIBUTOR, the organization they represent or are sponsored by (if any), The Internet Society, and the Internet Engineering Task Force all say they make no warranties at all, express or implied 🙈 that covers not infringing anyone's rights, and also merchantability and fitness for a particular purpose. it's giving "use at your own risk" energy 💀

Intellectual Property 🧚

the IETF doesn't take a side on whether any intellectual property rights that might cover this technology are valid or how far they reach, and it also doesn't claim to have checked for any of them 🫶 if you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 💜

IPR disclosures sent to the IETF Secretariat are posted, along with any licence assurances, and you can see whether someone tried to get a general licence or permission for implementers or users at the IETF on-line IPR repository at http://www.ietf.org/ipr ✨

the IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 🍓

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society 👑 thank you, legends 🥹