The MD4 MessageDigest Algorithm
RFC 1320
Document  Type 
RFC  Historic
(April 1992; Errata)
Obsoleted by RFC 6150
Obsoletes RFC 1186



Last updated  20130302  
Stream  IETF  
Formats  plain text pdf html bibtex  
Stream  WG state  (None)  
Document shepherd  No shepherd assigned  
IESG  IESG state  RFC 1320 (Historic)  
Consensus Boilerplate  Unknown  
Telechat date  
Responsible AD  (None)  
Send notices to  (None) 
Network Working Group R. Rivest Request for Comments: 1320 MIT Laboratory for Computer Science Obsoletes: RFC 1186 and RSA Data Security, Inc. April 1992 The MD4 MessageDigest Algorithm Status of thie Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Acknowlegements We would like to thank Don Coppersmith, Burt Kaliski, Ralph Merkle, and Noam Nisan for numerous helpful comments and suggestions. Table of Contents 1. Executive Summary 1 2. Terminology and Notation 2 3. MD4 Algorithm Description 2 4. Summary 6 References 6 APPENDIX A  Reference Implementation 6 Security Considerations 20 Author's Address 20 1. Executive Summary This document describes the MD4 messagedigest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD4 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a publickey cryptosystem such as RSA. The MD4 algorithm is designed to be quite fast on 32bit machines. In addition, the MD4 algorithm does not require any large substitution tables; the algorithm can be coded quite compactly. Rivest [Page 1] RFC 1320 MD4 MessageDigest Algorithm April 1992 The MD4 algorithm is being placed in the public domain for review and possible adoption as a standard. This document replaces the October 1990 RFC 1186 [2]. The main difference is that the reference implementation of MD4 in the appendix is more portable. For OSIbased applications, MD4's object identifier is md4 OBJECT IDENTIFIER ::= {iso(1) memberbody(2) US(840) rsadsi(113549) digestAlgorithm(2) 4} In the X.509 type AlgorithmIdentifier [3], the parameters for MD4 should have type NULL. 2. Terminology and Notation In this document a "word" is a 32bit quantity and a "byte" is an eightbit quantity. A sequence of bits can be interpreted in a natural manner as a sequence of bytes, where each consecutive group of eight bits is interpreted as a byte with the highorder (most significant) bit of each byte listed first. Similarly, a sequence of bytes can be interpreted as a sequence of 32bit words, where each consecutive group of four bytes is interpreted as a word with the loworder (least significant) byte given first. Let x_i denote "x sub i". If the subscript is an expression, we surround it in braces, as in x_{i+1}. Similarly, we use ^ for superscripts (exponentiation), so that x^i denotes x to the ith power. Let the symbol "+" denote addition of words (i.e., modulo2^32 addition). Let X <<< s denote the 32bit value obtained by circularly shifting (rotating) X left by s bit positions. Let not(X) denote the bitwise complement of X, and let X v Y denote the bitwise OR of X and Y. Let X xor Y denote the bitwise XOR of X and Y, and let XY denote the bitwise AND of X and Y. 3. MD4 Algorithm Description We begin by supposing that we have a bbit message as input, and that we wish to find its message digest. Here b is an arbitrary nonnegative integer; b may be zero, it need not be a multiple of eight, and it may be arbitrarily large. We imagine the bits of the message written down as follows: m_0 m_1 ... m_{b1} Rivest [Page 2] RFC 1320 MD4 MessageDigest Algorithm April 1992 The following five steps are performed to compute the message digest of the message. 3.1 Step 1. Append Padding Bits The message is "padded" (extended) so that its length (in bits) is congruent to 448, modulo 512. That is, the message is extended so that it is just 64 bits shy of being a multiple of 512 bits long. Padding is always performed, even if the length of the message is already congruent to 448, modulo 512. Padding is performed as follows: a single "1" bit is appended to theShow full document text