idnits 2.17.00 (12 Aug 2021) /tmp/idnits22056/draft-turner-md5-seccon-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1321, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2010) is 4337 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Turner 2 Internet Draft IECA 3 Updates: 1321 (once approved) L. Chen 4 Intended Status: Informational NIST 5 Expires: January 5, 2011 July 5, 2010 7 Updated Security Considerations for the MD5 Message-Digest Algorithm 8 draft-turner-md5-seccon-update-00.txt 10 Abstract 12 This document updates the security considerations for the MD5 message 13 digest algorithm. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 5, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 MD5 [MD5] is a message digest algorithm that takes as input a message 58 of arbitrary length and produces as output a 128-bit "fingerprint" or 59 "message digest" of the input. The published attacks against MD5 60 show and that it is not prudent to use MD5 when collision resistance 61 is required. This document replaces the security considerations in 62 RFC 1321 [MD5]. 64 [HASH-Attack] summarizes the use of hashes in many protocols and 65 discusses how attacks against a message digest algorithm's one-way 66 and collision-free properties affect and do not affect Internet 67 protocols. 69 2. Security Considerations 71 MD5 was published in 1992 as an Informational RFC. Since that time, 72 MD5 has been studied extensively. What follows are recent attacks 73 against MD5's collisions, pre-image, and second pre-image resistance. 74 Additionally, attacks against MD5 used in message authentication with 75 a shared secret (i.e., HMAC-MD5) are discussed. 77 Some may find the guidance for key lengths and algorithm strengths in 78 [SP800-57] and [SP800-131] useful. 80 2.1. Collision Resistance 82 The first paper that demonstrates actual collisions of MD5 was 83 published in 2004 [MD5-Analysis1]. The detailed attack techniques for 84 MD5 were published at EUROCRYPT 2005 [MD5-Analysis2]. Since then, a 85 lot of research results have been published to improve collision 86 attacks on MD5. The attacks presented in [MD5-Analysis3] can find MD5 87 collision in about one minute on a standard notebook PC (Intel 88 Pentium, 1.6 GHz.). In [MD5-Analysis4], the collision attack on MD5 89 was successfully applied to X.509 certificates. 91 Notice that the collision attack on MD5 can also be applied to 92 password based challenge-and-response authentication protocols such 93 as APOP protocol used in post office authentication as presented in 94 [MD5-Analysis5]. 96 In fact, more delicate attacks on MD5 to improve the speed of finding 97 collisions have published recently. However, the aforementioned 98 results have provided sufficient reason to eliminate MD5 usage in 99 applications where collision resistance is required such as digital 100 signatures. 102 2.2. Pre-image and Second Pre-image Resistance 104 Even though the best result can find a pre-image attack of MD5 faster 105 than exhaustive search as presented in [MD5-Analysis6], the 106 complexity 2^123.4 is still pretty high. 108 2.3. HMAC 110 The cryptanalysis of HMAC-MD5 usually conducted together with NMAC 111 (Nested MAC) since they are closely related. NMAC uses two 112 independent keys K1 and K2 such that NMAC(K1, K2, M) = H(K1, H(K2, 113 M), where K1 and K2 are used as secret IVs for hash functions 114 H(IV,M). If we re-write HMAC equation using two secret IVs such that 115 IV2 = H(K Xor ipad) and IV1 = H(K Xor opad), then HMAC(K, M) = 116 NMAC(IV1, IV2, M). Here it is very important to notice that IV1 and 117 IV2 are not independently selected. 119 The first analysis was explored on NMAC-MD5 using related keys in 120 [HMAC-Analysis1]. The partial key recovery attack cannot be extended 121 to HMAC-MD5, since for HMAC, recovering partial secret IVs can hardly 122 lead to recovering (partial) key K. Another paper presented at Crypto 123 2007 [HMAC-Analysis2] extended results of [HMAC-Analysis1] to a full 124 key recovery attack on NMAC-MD5. Since it also uses related key 125 attack, it does not seem applicable to HMAC-MD5. 127 A EUROCRYPT 2009 paper presented a distinguishing attack on HMAC-MD5 128 [HMAC-Analysis3] without using related keys. It can distinguish an 129 instantiation of HMAC with MD5 from an instantiation with a random 130 function with 2^97 queries with probability 0.87. This is called 131 distinguishing-H. Using the distinguishing attack, it can recover 132 some bits of the intermediate status of the second block. However, as 133 it is pointed in [HMAC-Analysis3], it cannot be used to recover the 134 (partial) inner key H(K Xor ipad). It is not obvious how the attack 135 can be used to form a forgery attack either. 137 The attacks on HMAC-MD5 do not seem to indicate a practical 138 vulnerability when used as a message authentication code. Considering 139 that the distinguishing-H attack is different from distinguishing-R 140 attack, which distinguishes an HMAC from a random function, the 141 practical impact on HMAC usage as a PRF such as in a key derivation 142 function is not well understood. 144 Therefore, it may not be urgent to remove HMAC-MD5 from the existing 145 protocols. However, since MD5 must not be used for digital 146 signatures, for a new protocol design, a ciphersuite with HMAC-MD5 147 should not be included. 149 3. IANA Considerations 151 None. 153 4. Normative References 155 [HASH-Attack] Hoffman, P., and B. Schneier, "Attacks on 156 Cryptographic Hashes in Internet Protocols", RFC 157 4270, November 2005. 159 [HMAC-Analysis1] S. Contini, Y.L. Yin. Forgery and partial key- 160 recovery attacks on HMAC and NMAC using hash 161 collisions. ASIACRYPT 2006. LNCS 4284, Springer, 162 2006. 164 [HMAC-Analysis2] Fouque, P.-A., Leurent, G., Nguyen, P.Q.: Full key- 165 recovery attacks on HMAC/NMAC-MD4 and NMAC-MD5. 166 CRYPTO 2007. LNCS, 4622, Springer, 2007. 168 [HMAC-Analysis3] X. Wang, H. Yu, W. Wang, H. Zhang, and T. Zhan. 169 Cryptanalysis of HMAC/NMAC-MD5 and MD5-MAC. LNCS 170 5479. Advances in Cryptology - EUROCRYPT2009, 171 Springer 2009. 173 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 174 1321, April 1992. 176 [MD5-Analysis1] X. Wang, D. Feng, X. Lai, H. Yu, Collisions for 177 Hash Functions MD4, MD5, HAVAL-128 and RIPEMD, 178 2004, http://eprint.iacr.org/2004/199.pdf 180 [MD5-Analysis2] X. Wang and H. Yu. How to Break MD5 and other Hash 181 Functions. LNCS 3494. Advances in Cryptology - 182 EUROCRYPT2005, Springer 2005. 184 [MD5-Analysis3] V. Klima. Tunnels in Hash Functions: MD5 Collisions 185 within a Minute. Cryptology ePrint Archive, Report 186 2006/105 (2006), http://eprint.iacr.org/2006/105. 188 [MD5-Analysis4] Stevens, M., Lenstra, A., de Weger, B., Target 189 Collisions for MD5 and Colliding X.509 190 Certificates for Different Identities. Cryptology 191 ePrint Archive, Report 2006/360 (2006), 192 http://eprint.iacr.org/2006/360. 194 [MD5-Analysis5] G. Leurent, Message freedom in MD4 and MD5 195 collisions: Application to APOP. Proceedings of 196 FSE 2007. Lecture Notes in Computer Science 4715. 197 Springer 2007. 199 [MD5-Analysis6] Y. Sasaki and K. Aoki. Finding preimages in full 200 MD5 faster than exhaustive search. Advances in 201 Cryptology - EUROCRYPT 2009, LNCS 5479 of Lecture 202 Notes in Computer Science, Springer, 2009. 204 [SP800-57] National Institute of Standards and Technology 205 (NIST), Special Publication 800-57: Recommendation 206 for Key Management - Part 1 (Revised), March 2007. 208 [SP800-131] National Institute of Standards and Technology 209 (NIST), Special Publication 800-131: DRAFT 210 Recommendation for the Transitioning of 211 Cryptographic Algorithms and Key Sizes, June 2010. 213 Authors' Addresses 215 Sean Turner 216 IECA, Inc. 217 3057 Nutley Street, Suite 106 218 Fairfax, VA 22031 219 USA 221 EMail: turners@ieca.com 223 Lily Chen 224 National Institute of Standards and Technology 225 100 Bureau Drive, Mail Stop 8930 226 Gaithersburg, MD 20899-8930 227 USA 229 EMail: lily.chen@nist.gov