Reverse path forwarding (RPF)

Reverse path forwarding (RPF) is a technique used in modern routers for the purposes of ensuring loop-free forwarding of multicast packets in multicast routing and to help prevent IP address spoofing in unicast routing.

Contents 1 Multicast RPF 2 Unicast RPF (uRPF) 3 Unicast RPF confusion 4 External links

Multicast RPF

Multicast RPF, typically denoted simply as RPF, is used in conjunction with multicast routing protocols such as MSDP and PIM-SM to ensure loop-free forwarding of multicast packets. In multicast routing the decision to forward traffic is based upon source address and not on destination address as is the case with unicast routing. It does this by utilizing either a dedicated multicast routing table or alternatively the router's native unicast routing table.

When a multicast packet enters a router's interface it will lookup the list of networks that are reachable via that input interface i.e., it checks the reverse path of the packet. If the router finds a matching routing entry for the source IP of the multicast packet, the RPF check passes and the packet is forwarded to all other interfaces that are participating in multicast for this multicast group. If the RPF check fails the packet will be dropped. As a result the forwarding of the packet is decided based upon the reverse path of the packet rather than the forward path. RPF routers only forward packets that come into the interface that also hold the routing entry for the source of the packet, thus breaking any loop.

This is critically important in redundant multicast topologies. Because the same multicast packet could reach the same router via multiple interfaces, RPF checking must be integral in the decision to forward packets or not. If the router forwarded all packets that come in interface A to interface B and it also forwarded all packets coming in interface B to interface A and both interfaces receive the same packet, this will create a classic routing loop where packets will be forwarded in both directions until their IP TTLs expire. Even considering TTL expiry, all types of routing loops are best avoided as they involve at least temporary network degradation.

Unicast RPF (uRPF)

uRPF as defined in RFC 3704 is an evolution of the concept that traffic from known invalid networks should not be accepted on interfaces from which they should never have originated. The original idea as seen in RFC 2827 was to block traffic on an interface if it is sourced from RFC 1918 private addresses. It is a reasonable assumption for many organizations to simply disallow propagation of private addresses on their networks unless they are explicitly in use. This is a great benefit to the internet backbone as blocking packets from obviously bogus source addresses helps to cut down on IP address spoofing which is commonly used in DoS, DDoS, and network scanning to obfuscate the source of the scan.

uRPF dramatically extends this idea by utilizing the knowledge all routers must have to do their jobs, their routing table, to help further restrict the possible sources addresses that should be seen on an interface. Packets are only forwarded if they come from router's best route to the source of a packet, ensuring that:-

1. Packets coming into an interface come from (potentially) valid hosts, as indicated by the corresponding entry in the routing table.
2. Packets with source addresses that could not be reached via the input interface can be dropped without disruption to normal use, as they are probably from a misconfigured or malicious source.

In cases of symmetric routing, routing where packets flow forward and reverse down the same path, and terminal networks with only one link this is a safe assumption and uRPF can be implemented without much fear of problems. It is particularly useful to implement RPF on routers interfaces that are connected to singly homed networks and terminal subnets as symmetric routing is guaranteed. Using uRPF as close as possible to the real source of traffic also stops spoofed traffic before it has any chance of using internet bandwidth or reaching a router which is not configured for RPF and thus inappropriately forwarded.

Unfortunately, it is often the case on the larger internet backbone that routing is asymmetric and you cannot count on the routing table to point to the best route for a source to get to a router. Routing tables specify best forward path and only in the symmetric case does that equate to the best reverse path. Because of this common asymmetry it is important when implementing uRPF to be aware of the potential for asymmetry to exist to prevent accidental filtering of legitimate traffic.

RFC 3704 gives more details on how to extend the most basic "this source address must be seen in the routing table for the input interface" concept known as Strict Reverse Path Forwarding to include some more relaxed cases that can still be of benefit while allowing for at least some asymmetry.

As one final note, any device using a default route cannot use uRPF on the interface that the default route points to because all sources would be allowed to come from that interface and uRPF would not accomplish even as much as RFC 2827.

Unicast RPF confusion

RPF is often incorrectly defined as Reverse Path Filtering, particularly when it comes to unicast routing. This is an understandable misinterpretation of the acronym in that when RPF is used with unicast routing as in RFC 3704 traffic is either permitted or denied based upon the RPF check passing or failing. The thought being that traffic is denied if it fails the RPF check and is therefore filtered, however as per RFC 3704 the correct interpretation is that traffic is forwarded if it passes the RPF check. Several examples of the proper usage can be seen in documents by Juniper, Cisco, OpenBSD, and most importantly RFC 3704 which defines the use of RPF with unicast.

While uRPF is used as in ingress filtering mechanism, it is affected by reverse path forwarding.

External links

• RFC 2827
• RFC 3704
• Juniper - Configuring uRPF
• Cisco - Understanding uRPF
• OpenBSD - Enabling uRPF in pf
• Juniper Networks on multicast RPF

Retrieved from "http://en.wikipedia.org/wiki/Reverse_path_forwarding"

Categories: Routing

Cryptographic hash function

A cryptographic hash function is a transformation that takes an input (or 'message') and returns a fixed-size string, which is called the hash value (sometimes termed a message digest, a digital fingerprint, a digest or a checksum). The ideal hash function has three main properties - it is extremely easy to calculate a hash for any given data, it is extremely difficult or almost impossible in a practical sense to calculate a text that has a given hash, and it is extremely unlikely that two different messages, however close, will have the same hash.

Functions with these properties are used as hash functions for a variety of purposes, both within and outside cryptography. Practical applications include message integrity checks, digital signatures, authentication, and various information security applications. A hash can also act as a concise representation of the message or document from which it was computed, and allows easy indexing of duplicate or unique data files.

In various standards and applications, the two most commonly used hash functions are MD5 and SHA-1 (other well known hash functions are listed below). In 2005, security flaws were identified in both of these, namely that a possible mathematical weakness might exist, indicating that a stronger hash function would be desirable. In 2007 the National Institute of Standards and Technology announced a contest to design a hash function which will be given the name SHA-3 and be the subject of a FIPS standard.^[1]

Contents 1 Overview 2 Related algorithms 3 Cryptographic properties 4 Applications 5 Merkle-Damgård construction 6 Hash functions based on block ciphers 6.1 Methods to make hash functions from block ciphers 7 Use in building other cryptographic primitives 8 Concatenation of cryptographic hash functions 9 List of cryptographic hash functions 10 See also 11 References 12 Further reading 13 External links

Overview

Even small changes in the source input drastically change the resulting output, also known as Avalanche effect.

A hash function takes a string of any length as input and produces a fixed length string which acts as a kind of "signature" for the data provided. In this way, a person knowing the hash is unable to work out the original message, but someone knowing the original message can prove the hash is created from that message, and none other. A cryptographic hash function should behave as much as possible like a random function while still being deterministic and efficiently computable.

A cryptographic hash function is considered "insecure" from a cryptographic point of view, if either of the following is computationally feasible:

• finding a (previously unseen) message that matches a given digest
• finding "collisions", wherein two different messages have the same message digest.

An attacker who can do either of these things might, for example, use them to substitute an authorized message with an unauthorized one.

Ideally, it should not even be feasible to find two messages whose digests are substantially similar; nor would one want an attacker to be able to learn anything useful about a message given only its digest. Of course the attacker learns at least one piece of information, the digest itself, which for instance gives the attacker the ability to recognise the same message should it occur again.

Related algorithms

Checksums and cyclic redundancy checks (CRCs) are quite distinct from cryptographic hash functions, and are used for different applications. If used for security, they are vulnerable to attack; for example, a CRC was used for message integrity in the WEP encryption standard, but an attack was readily discovered which exploited the linearity of the checksum specified.

A message authentication code (MAC) takes a message and a secret key and generates a "MAC tag", such that it is difficult for an attacker to generate a valid pair (message, tag) that doesn't match one they've already seen; they are used to prevent attackers forging messages, among other uses. Though it is sometimes referred to as a "keyed hash function", a MAC serves a very different purpose and has very different security properties than a cryptographic hash function; for example, it is not considered a flaw if it is easy for someone who knows the MAC key to generate two messages that have the same MAC. Hash functions can be used to create MAC functions; see for example HMAC.

Cryptographic properties

There is no formal definition which captures all of the properties considered desirable for a cryptographic hash function. These properties below are generally considered prerequisites:

• Preimage resistant (See one way function for a related but slightly different property): given h it should be hard to find any m such that h = hash(m).
• Second preimage resistant: given an input m₁, it should be hard to find another input, m₂ (not equal to m₁) such that

hash(m₁) = hash(m₂).

This property is implied by collision-resistance. Second preimage resistance is sometimes referred to as weak collision resistance.

• Collision-resistant: it should be hard to find two different messages m₁ and m₂ such that hash(m₁) = hash(m₂). Due to a possible birthday attack, this means the hash function output must be at least twice as large as what is required for preimage-resistance. This property is sometimes referred to as strong collision resistance.

A hash function meeting these criteria may still have undesirable properties. For instance, many popular hash functions are vulnerable to length-extension attacks: given h(m) and len(m) but not m, by choosing a suitable m' an attacker can calculate h (m || m'), where || denotes concatenation. This property can be used to break naive authentication schemes based on hash functions. The HMAC construction works around these problems.

It is however, a common misconception that "one-wayness" of a cryptographic hash function means irreversibility of processing of the hash state, and that it somehow contradicts the principles used to construct block ciphers. Such "irreversibility" in fact means presence of local collisions that could facilitate attacks. The hash function must be a permutation processing its state bijectively to be cryptographically secure. It must be irreversible regarding the data block just like any block cipher must be irreversible regarding the key (it should be impossible to find the key that can encrypt a block A into a block B faster than the brute-force). This makes iterated block ciphers and hash functions processing blocks of the same size as secret keys of those block ciphers virtually identical, except the roles of key and data blocks are swapped. All the attacks against the MDx and SHA families of hash functions exploit local collisions in the processing of the data block. The local collisions caused by the final addition operation can also be exploited by these attacks.

Applications

A typical use of a cryptographic hash would be as follows: Alice poses a tough math problem to Bob, and claims she has solved it. Bob would like to try it himself, but would yet like to be sure that Alice is not bluffing. Therefore, Alice writes down her solution, appends a random nonce, computes its hash and tells Bob the hash value (whilst keeping the solution and nonce secret). This way, when Bob comes up with the solution himself a few days later, Alice can prove that she had the solution earlier by revealing the nonce to Bob. (This is an example of a simple commitment scheme; in actual practice, Alice and Bob will often be computer programs, and the secret would be something less easily spoofed than a claimed puzzle solution).

Another important application of secure hashes is verification of message integrity. Determining whether any changes have been made to a message (or a file), for example, can be accomplished by comparing message digests calculated before, and after, transmission (or any other event).

A message digest can also serve as a means of reliably identifying a file; several source code management systems, including Git, Mercurial and Monotone, use the sha1sum of various types of content (file content, directory trees, ancestry information, etc) to uniquely identify them.

A related application is password verification. Passwords are usually not stored in cleartext, for obvious reasons, but instead in digest form. To authenticate a user, the password presented by the user is hashed and compared with the stored hash. This is sometimes referred to as one-way encryption.

For both security and performance reasons, most digital signature algorithms specify that only the digest of the message be "signed", not the entire message. Hash functions can also be used in the generation of pseudorandom bits.

SHA-1, MD5, and RIPEMD-160 are among the most commonly-used message digest algorithms as of 2005. In August 2004, researchers found weaknesses in a number of hash functions, including MD5, SHA-0 and RIPEMD. This has called into question the long-term security of later algorithms which are derived from these hash functions — in particular, SHA-1 (a strengthened version of SHA-0), RIPEMD-128, and RIPEMD-160 (both strengthened versions of RIPEMD). Neither SHA-0 nor RIPEMD are widely used since they were replaced by their strengthened versions. In February 2005, an attack on SHA-1 was reported, finding collisions in about 2⁶⁹ hashing operations, rather than the 2⁸⁰ expected for a 160-bit hash function. In August 2005, another attack on SHA-1 was reported, finding collisions in 2⁶³ operations.

Hashes are used to identify files on peer-to-peer filesharing networks. For example, in an ed2k link, an MD4-variant hash is combined with the file size, providing sufficient information for locating file sources, downloading the file and verifying its contents. Magnet links are another example. Such file hashes are often the top hash of a hash list or a hash tree which allows for additional benefits.

Merkle-Damgård construction

Main article: Merkle-Damgård construction

The Merkle-Damgård hash construction.

A hash function must be able to process an arbitrary-length message into a fixed-length output. This can be achieved by breaking the input up into a series of equal-sized blocks, and operating on them in sequence using a one-way compression function. The compression function can either be specially designed for hashing or be built from a block cipher. A hash function built with the Merkle-Damgård construction is as resistant to collisions as is its compression function; any collision for the full hash function can be traced back to a collision in the compression function.

The last block processed should also be unambiguously length padded; this is crucial to the security of this construction. This construction is called the Merkle-Damgård construction. Most widely used hash functions, including SHA-1 and MD5, take this form.

Hash functions based on block ciphers

Main article: One-way compression function

There are several methods to use a block cipher to build a cryptographic hash function. The methods resemble the block cipher modes of operation usually used for encryption. All well-known hash functions, including MD4, MD5, SHA-1 and SHA-2 are built from block-cipher-like components designed for the purpose, with feedback to ensure that the resulting function is not bijective.

A standard block cipher such as AES can be used in place of these custom block ciphers; this generally carries a cost in performance, but can be advantageous where a system needs to perform hashing and another cryptographic function such as encryption that might use a block cipher, but is constrained in the code size or hardware area it must fit into, such as in some embedded systems like smart cards.

Methods to make hash functions from block ciphers

See one-way compression function for details.

• Davies-Meyer
• Matyas-Meyer-Oseas
• Miyaguchi-Preneel
• MDC-2
• MDC-4

Use in building other cryptographic primitives

Hash functions can be used to build other cryptographic primitives. For these other primitives to be cryptographically secure care has to be taken to build them the right way.

Message authentication codes (MACs) are often built from hash functions. HMAC is such a MAC.

Just as block ciphers can be used to build hash functions, hash functions can be used to build block ciphers. Examples of such block ciphers are SHACAL, BEAR and LION.

Pseudorandom number generators (PRNGs) can be built using hash functions. This is done by combining a (secret) random seed with a counter and hashing it. If the counter is a bignum (allowed to count to any size) then the PRNG can have an infinite period.

Stream ciphers can be built using hash functions. Often this is done by first building a cryptographically secure pseudorandom number generator and then using its stream of random bytes as keystream and XOR that onto the cleartext to get the ciphertext. SEAL is such a stream cipher which is based on SHA-1.

Concatenation of cryptographic hash functions

Concatening multiple hash functions could produce a new hash function that is more secure than its component parts.^[2] For example, one might concatenate the output of SHA-1 and RIPEMD-160 to produce a new function H(x) = SHA-1(x) || RIPEMD-160(x).

However, the new function is still no more secure than each of its component parts in isolation. Joux ^[3] noted that the iterative nature of cryptographic hash functions introduces a weakness. n-collisions (n different messages that hash to the same value) are effectively no more difficult to find than 2-collisions. If an n-collision can be found for RIPEMD, it is likely that amongst the n different messages there will be a collision in SHA-1. The time needed to find the SHA-1 collision is polynomial. This argument is summarized by Finney.

Concatenated hash functions are used within SSL and the Debian Advanced Packaging Tool system, both of which currently use concatenated MD5 and SHA-1 sums. This does not increase security, but provides redundancy in case one is broken: a valid reason for using multiple hash functions.

List of cryptographic hash functions

This section does not cite any references or sources. Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed. (May 2008)

Some of the following algorithms are known to be insecure; consult the article for each specific algorithm for more information on the status of each algorithm. For even more hash functions see the box at the bottom of the page.

Algorithm	Output size (bits)	Internal state size	Block size	Length size	Word size	Collision
HAVAL	256/224/192/160/128	256	1024	64	32	Yes
MD2	128	384	128	No	8	Almost
MD4	128	128	512	64	32	Yes
MD5	128	128	512	64	32	Yes
PANAMA	256	8736	256	No	32	Yes
RadioGatún	Arbitrarily long	58 words	3 words	No	1-64	No
RIPEMD	128	128	512	64	32	Yes
RIPEMD-128/256	128/256	128/256	512	64	32	No
RIPEMD-160/320	160/320	160/320	512	64	32	No
SHA-0	160	160	512	64	32	Yes
SHA-1	160	160	512	64	32	With flaws
SHA-256/224	256/224	256	512	64	32	No
SHA-512/384	512/384	512	1024	128	64	No
Tiger(2)-192/160/128	192/160/128	192	512	64	64	No
WHIRLPOOL	512	512	512	256	8	No

The SHA hash functions are a series of functions developed by the NSA: SHA, also known as SHA-0, SHA-1 and four flavours of a function known as SHA-2.

Note: The internal state here means the "internal hash sum" after each compression of a data block. Most hash algorithms also internally use some additional variables such as length of the data compressed so far since that is needed for the length padding in the end. See the Merkle-Damgård construction for details.

See also

• Avalanche effect
• MD5CRK
• Message authentication code
• Keyed-hash message authentication code
• CRHF - Collision Resistant Hash Functions.
• UOWHF - Universal One Way Hash Functions.
• CRYPTREC and NESSIE - Projects which recommend hash functions.
• PGP word list

References

1. ^ NIST.gov - Computer Security Division - Computer Security Resource Center
2. ^ [1] suggested
3. ^ Joux, Antoine. Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions. LNCS 3152/2004, pages 306-316 Full text.

Further reading

• Bruce Schneier. Applied Cryptography. John Wiley & Sons, 1996. ISBN 0-471-11709-9.

External links

• Hash'em all! — free online text and file hashing with different algorithms
• The Hash function lounge — a list of hash functions and known attacks
• Hash functions: Theory, attacks, and applications — a survey by Ilya Mironov (Microsoft Research)
• Helger Lipmaa's links on hash functions
• Diagrams explaining cryptographic hash functions
• An Illustrated Guide to Cryptographic Hashes by Steve Friedl
• Cryptanalysis of MD5 and SHA: Time for a New Standard by Bruce Schneier
• Hash collision Q&A
• Attacking hash functions by poisoned messages (construction of multiple sensible Postscript messages with the same hash function)
• What is a hash function? from RSA Laboratories
• Password Hashing in PHP by James McGlinn at the PHP Security Consortium
• The code monkey's guide to cryptographic hashes by Val Henson, "in language that any programmer (and even some managers) can understand."
• File Hash for Windows with various algorithms

v • d • e Cryptographic hash functions and Message authentication codes (MACs) Hash algorithms: GOST | HAS-160 | HAVAL | MDC-2 | MD2 | MD4 | MD5 | N-Hash | RadioGatún | RIPEMD | SHA family | Snefru | Tiger | WHIRLPOOL | crypt(3) DES MAC algorithms: DAA | CBC-MAC | HMAC | OMAC/CMAC | PMAC | UMAC | Poly1305-AES Authenticated encryption modes: CCM | CWC | EAX | GCM | OCB Attacks: Hash collision | Birthday attack | Preimage attack | Rainbow table | Side channel attack | Brute force attack Misc: Avalanche effect | Hash collision | Merkle-Damgård construction Standardization: CRYPTREC | NESSIE v • d • e Cryptography History of cryptography | Cryptanalysis | Cryptography portal | Topics in cryptography Symmetric-key algorithm | Block cipher | Stream cipher | Public-key cryptography | Cryptographic hash function | Message authentication code | Random numbers | Steganography

Retrieved from "http://en.wikipedia.org/wiki/Cryptographic_hash_function"

Categories: Cryptography | Cryptographic primitives | Cryptographic hash functions | Hashing | CISSP

MD5 Algorithm

MD5
General
Designers	Ron Rivest
First published	April 1992
Series	MD, MD2, MD3, MD4, MD5
Detail
Digest sizes	128 bits
Rounds	4

In cryptography, MD5 (Message-Digest algorithm 5) is a widely used, partially insecure^[1] cryptographic hash function with a 128-bit hash value. As an Internet standard (RFC 1321), MD5 has been employed in a wide variety of security applications, and is also commonly used to check the integrity of files. An MD5 hash is typically expressed as a 32 digit hexadecimal number.

MD5 was designed by Ron Rivest in 1991 to replace an earlier hash function, MD4. In 1996, a flaw was found with the design of MD5. While it was not a clearly fatal weakness, cryptographers began recommending the use of other algorithms, such as SHA-1 (which has since been found vulnerable itself). In 2004, more serious flaws were discovered making further use of the algorithm for security purposes questionable.^[2][3] In 2007 a group of researchers including Arjen Lenstra described how to create a pair of files that share the same MD5 checksum.^[4]

Contents 1 History and cryptanalysis 2 Vulnerability 3 Applications 4 Algorithm 4.1 Pseudocode 5 MD5 hashes 6 Notes 7 References 8 See also 9 External links 9.1 Test Vectors

History and cryptanalysis

Message Digest is a series of message digest algorithms designed by Professor Ronald Rivest of MIT (Rivest, 1994). When analytic work indicated that MD5's predecessor—MD4—was likely to be insecure, MD5 was designed in 1991 to be a secure replacement. (Weaknesses were indeed later found in MD4 by Hans Dobbertin.)

In 1993, Den Boer and Bosselaers gave an early, although limited, result of finding a "pseudo-collision" of the MD5 compression function; that is, two different initialization vectors which produce an identical digest.

In 1996, Dobbertin announced a collision of the compression function of MD5 (Dobbertin, 1996). While this was not an attack on the full MD5 hash function, it was close enough for cryptographers to recommend switching to a replacement, such as WHIRLPOOL, SHA-1 or RIPEMD-160.

The size of the hash—128 bits—is small enough to contemplate a birthday attack. MD5CRK was a distributed project started in March 2004 with the aim of demonstrating that MD5 is practically insecure by finding a collision using a birthday attack.

MD5CRK ended shortly after 17 August, 2004, when collisions for the full MD5 were announced by Xiaoyun Wang, Dengguo Feng, Xuejia Lai, and Hongbo Yu.^[2][5][3] Their analytical attack was reported to take only one hour on an IBM p690 cluster.

On 1 March 2005, Arjen Lenstra, Xiaoyun Wang, and Benne de Weger demonstrated^[6] construction of two X.509 certificates with different public keys and the same MD5 hash, a demonstrably practical collision. The construction included private keys for both public keys. A few days later, Vlastimil Klima described^[7] an improved algorithm, able to construct MD5 collisions in a few hours on a single notebook computer. On 18 March 2006, Klima published an algorithm^[8] that can find a collision within one minute on a single notebook computer, using a method he calls tunneling.

Vulnerability

Because MD5 makes only one pass over the data, if two prefixes with the same hash can be constructed, a common suffix can be added to both to make the collision more reasonable.

Because the current collision-finding techniques allow the preceding hash state to be specified arbitrarily, a collision can be found for any desired prefix; that is, for any given string of characters X, two colliding files can be determined which both begin with X.

All that is required to generate two colliding files is a template file, with a 128-byte block of data aligned on a 64-byte boundary, that can be changed freely by the collision-finding algorithm.

Recently, a number of projects have created MD5 "rainbow tables" which are easily accessible online, and can be used to reverse many MD5 hashes into strings that collide with the original input, usually for the purposes of password cracking. However, if passwords are combined with a salt before the MD5 digest is generated, rainbow tables become much less useful.

The use of MD5 in some websites' URLs means that Google can also sometimes function as a limited tool for reverse lookup of MD5 hashes.^[9] This technique is rendered ineffective by the use of a salt.

Applications

This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. (August 2008)

MD5 digests have been widely used in the software world to provide some assurance that a transferred file has arrived intact. For example, file servers often provide a pre-computed MD5 checksum for the files, so that a user can compare the checksum of the downloaded file to it. Unix-based operating systems include MD5 sum utilities in their distribution packages, whereas Windows users use third-party applications.

However, now that it is easy to generate MD5 collisions, it is possible for the person who created the file to create a second file with the same checksum, so this technique cannot protect against some forms of malicious tampering. Also, in some cases the checksum cannot be trusted (for example, if it was obtained over the same channel as the downloaded file), in which case MD5 can only provide error-checking functionality: it will recognize a corrupt or incomplete download, which becomes more likely when downloading larger files.

MD5 is widely used to store passwords. To mitigate against the vulnerabilities mentioned above, one can add a salt to the passwords before hashing them. Some implementations may apply the hashing function more than once—see key strengthening.

Algorithm

Figure 1. One MD5 operation-MD5 consists of 64 of these operations, grouped in four rounds of 16 operations. F is a nonlinear function; one function is used in each round. M_i denotes a 32-bit block of the message input, and K_i denotes a 32-bit constant, different for each operation.

_s denotes a left bit rotation by s places; s varies for each operation. denotes addition modulo 2³².

MD5 processes a variable-length message into a fixed-length output of 128 bits. The input message is broken up into chunks of 512-bit blocks (sixteen 32-bit little endian integers); the message is padded so that its length is divisible by 512. The padding works as follows: first a single bit, 1, is appended to the end of the message. This is followed by as many zeros as are required to bring the length of the message up to 64 bits fewer than a multiple of 512. The remaining bits are filled up with a 64-bit integer representing the length of the original message, in bits.

The main MD5 algorithm operates on a 128-bit state, divided into four 32-bit words, denoted A, B, C and D. These are initialized to certain fixed constants. The main algorithm then operates on each 512-bit message block in turn, each block modifying the state. The processing of a message block consists of four similar stages, termed rounds; each round is composed of 16 similar operations based on a non-linear function F, modular addition, and left rotation. Figure 1 illustrates one operation within a round. There are four possible functions F; a different one is used in each round:

denote the XOR, AND, OR and NOT operations respectively.

Pseudocode

Pseudocode for the MD5 algorithm follows.

//Note: All variables are unsigned 32 bits and wrap modulo 2^32 when calculating

var int[64] r, k



//r specifies the per-round shift amounts

r[ 0..15] := {7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22}

r[16..31] := {5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20}

r[32..47] := {4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23}

r[48..63] := {6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21}



//Use binary integer part of the sines of integers (Radians) as constants:

for i from 0 to 63

  k[i] := floor(abs(sin(i + 1)) × (2 pow 32))



//Initialize variables:

var int h0 := 0x01234567

var int h1 := 0x89ABCDEF

var int h2 := 0xFEDCBA98

var int h3 := 0x76543210



//Pre-processing:

append "1" bit to message

append "0" bits until message length in bits ≡ 448 (mod 512)

append bit /* bit, not byte */ length of unpadded message as 64-bit little-endian integer to message



//Process the message in successive 512-bit chunks:

for each 512-bit chunk of message

  break chunk into sixteen 32-bit little-endian words w[i], 0 ≤ i ≤ 15



  //Initialize hash value for this chunk:

  var int a := h0

  var int b := h1



  var int c := h2

  var int d := h3



  //Main loop:

  for i from 0 to 63

      if 0 ≤ i ≤ 15 then

          f := (b and c) or ((not b) and d)

          g := i

      else if 16 ≤ i ≤ 31

          f := (d and b) or ((not d) and c)

          g := (5×i + 1) mod 16

      else if 32 ≤ i ≤ 47

          f := b xor c xor d

          g := (3×i + 5) mod 16

      else if 48 ≤ i ≤ 63

          f := c xor (b or (not d))

          g := (7×i) mod 16



      temp := d

      d := c

      c := b

      b := b + leftrotate((a + f + k[i] + w[g]) , r[i])

      a := temp



  //Add this chunk's hash to result so far:

  h0 := h0 + a

  h1 := h1 + b

  h2 := h2 + c

  h3 := h3 + d



var int digest := h0 append h1 append h2 append h3 //(expressed as little-endian)

  //leftrotate function definition

leftrotate (x, c)

    return (x <<>or (x >> (32-c));

Note: Instead of the formulation from the original RFC 1321 shown, the following may be used for improved efficiency (useful if assembly language is being used - otherwise, the compiler will generally optimize the above code. Since each computation is dependent on another in these formulations, this is often slower than the above method where the nand/and can be parallelised):

(0  ≤ i ≤ 15): f := d xor (b and (c xor d))

(16 ≤ i ≤ 31): f := c xor (d and (b xor c))

MD5 hashes

The 128-bit (16-byte) MD5 hashes (also termed message digests) are typically represented as a sequence of 32 hexadecimal digits. The following demonstrates a 43-byte ASCII input and the corresponding MD5 hash:

 MD5("The quick brown fox jumps over the lazy dog")

= 9e107d9d372bb6826bd81d3542a419d6

Even a small change in the message will (with overwhelming probability) result in a completely different hash, due to the avalanche effect. For example, adding a period to the end of the sentence:

 MD5("The quick brown fox jumps over the lazy dog.")

= e4d909c290d0fb1ca068ffaddf22cbd0

The hash of the zero-length string is:

 MD5("")

= d41d8cd98f00b204e9800998ecf8427e

Notes

1. ^ Xiaoyun Wang and Hongbo Yu: How to Break MD5 and Other Hash Functions. Retrieved July 27, 2008
2. ^ ^{a b} Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu: Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD, Cryptology ePrint Archive Report 2004/199, 16 Aug 2004, revised 17 Aug 2004. Retrieved July 27, 2008.
3. ^ ^{a b} J. Black, M. Cochran, T. Highland: A Study of the MD5 Attacks: Insights and Improvements, March 3, 2006. Retrieved July 27, 2008.
4. ^ Marc Stevens, Arjen Lenstra, Benne de Weger: Vulnerability of software integrity and code signing applications to chosen-prefix collisions for MD5, Nov 30, 2007. Retrived Jul 27, 2008.
5. ^ Philip Hawkes and Michael Paddon and Gregory G. Rose: Musings on the Wang et al. MD5 Collision, 13 Oct 2004. Retrieved July 27, 2008.
6. ^ Arjen Lenstra, Xiaoyun Wang, Benne de Weger: Colliding X.509 Certificates, Cryptology ePrint Archive Report 2005/067, 1 Mar 2005, revised 6 May 2005. Retrieved July 27, 2008.
7. ^ Vlastimil Klima: Finding MD5 Collisions – a Toy For a Notebook, Cryptology ePrint Archive Report 2005/075, 5 Mar 2005, revised 8 Mar 2005. Retrieved July 27, 2008.
8. ^ Vlastimil Klima: Tunnels in Hash Functions: MD5 Collisions Within a Minute, Cryptology ePrint Archive Report 2006/105, 18 Mar 2006, revised 17 Apr 2006. Retrueved July 27, 2008.
9. ^ Steven J. Murdoch: Google as a password cracker, Light Blue Touchpaper Blog Archive, Nov 16, 2007. Retrieved July 27, 2008.]

References

• Berson, Thomas A. (1992). "Differential Cryptanalysis Mod 2³² with Applications to MD5". EUROCRYPT: 71–80. ISBN 3-540-56413-6.
• Bert den Boer; Antoon Bosselaers (1993). Collisions for the Compression Function of MD5, 293–304. ISBN 3-540-57600-2.
• Hans Dobbertin, Cryptanalysis of MD5 compress. Announcement on Internet, May 1996 [1].
• Dobbertin, Hans (1996). "The Status of MD5 After a Recent Attack". CryptoBytes 2 (2).
• Xiaoyun Wang; Hongbo Yu (2005). "How to Break MD5 and Other Hash Functions". EUROCRYPT. ISBN 3-540-25910-4.

See also

• md5deep

External links

The external links in this article may not follow Wikipedia's content policies or guidelines. Please improve this article by removing excessive or inappropriate external links.

• RFC 1321 The MD5 Message-Digest Algorithm
• W3C recommendation on MD5
• Two colliding PostScript files with the same size
• Two colliding executable files
• Delphi, Java, JavaScript, Perl, PHP, and Python implementations of MD5
• Online MD5 hash generator
• Filesystem-based MD5 tool
• MD5 Collision Generation

Test Vectors

The NESSIE project test vectors for MD5

v • d • e Cryptographic hash functions and Message authentication codes (MACs) Hash algorithms: GOST | HAS-160 | HAVAL | MDC-2 | MD2 | MD4 | MD5 | N-Hash | RadioGatún | RIPEMD | SHA family | Snefru | Tiger | WHIRLPOOL | crypt(3) DES MAC algorithms: DAA | CBC-MAC | HMAC | OMAC/CMAC | PMAC | UMAC | Poly1305-AES Authenticated encryption modes: CCM | CWC | EAX | GCM | OCB Attacks: Hash collision | Birthday attack | Preimage attack | Rainbow table | Side channel attack | Brute force attack Misc: Avalanche effect | Hash collision | Merkle-Damgård construction Standardization: CRYPTREC | NESSIE v • d • e Cryptography History of cryptography | Cryptanalysis | Cryptography portal | Topics in cryptography Symmetric-key algorithm | Block cipher | Stream cipher | Public-key cryptography | Cryptographic hash function | Message authentication code | Random numbers | Steganography

Retrieved from "http://en.wikipedia.org/wiki/MD5"

Categories: Cryptographic hash functions | Checksum algorithms | Articles with example pseudocode