Results 1 
7 of
7
MerkleDamg˚ard Revisited: How to Construct a Hash Function
 Advances in Cryptology, Crypto 2005
"... The most common way of constructing a hash function (e.g., SHA1) is to iterate a compression function on the input message. The compression function is usually designed from scratch or made out of a blockcipher. In this paper, we introduce a new security notion for hashfunctions, stronger than col ..."
Abstract

Cited by 84 (8 self)
 Add to MetaCart
(Show Context)
The most common way of constructing a hash function (e.g., SHA1) is to iterate a compression function on the input message. The compression function is usually designed from scratch or made out of a blockcipher. In this paper, we introduce a new security notion for hashfunctions, stronger than collisionresistance. Under this notion, the arbitrary length hash function H must behave as a random oracle when the fixedlength building block is viewed as a random oracle or an ideal blockcipher. The key property is that if a particular construction meets this definition, then any cryptosystem proven secure assuming H is a random oracle remains secure if one plugs in this construction (still assuming that the underlying fixedlength primitive is ideal). In this paper, we show that the current design principle behind hash functions such as SHA1 and MD5 — the (strengthened) MerkleDamg˚ard transformation — does not satisfy this security notion. We provide several constructions that provably satisfy this notion; those new constructions introduce minimal changes to the plain MerkleDamg˚ard construction and are easily implementable in practice.
Prashant PuniyaThe Random Oracle Methodology
"... ♦ “Paradigm for designing secure and efficient protocols ” (BR’93). ♦ Assume existence of a publicly accessible ideal random function and prove protocol security. ♦ Replace ideal random function by an actual “secure hash function ” (such as SHA1) to deploy protocol. ♦ Hope that nothing breaks down! ..."
Abstract
 Add to MetaCart
(Show Context)
♦ “Paradigm for designing secure and efficient protocols ” (BR’93). ♦ Assume existence of a publicly accessible ideal random function and prove protocol security. ♦ Replace ideal random function by an actual “secure hash function ” (such as SHA1) to deploy protocol. ♦ Hope that nothing breaks down! Is SHA1 Really Random? ♦ Is SHA1 obscure enough to successfully replace a random oracle? ♦ No. Practical hash functions usually iteratively apply a fixed length compression function to the input (called the Merkle Damgard construction). f f f
On the Generic Insecurity of the Full Domain
"... Abstract. The FullDomain Hash (FDH) signature scheme [3] forms one the most basic usages of random oracles. It works with a family F of trapdoor permutations (TDP), where the signature of m is computed as f −1 (h(m)) (here f ∈R F and h is modelled as a random oracle). It is known to be existentiall ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract. The FullDomain Hash (FDH) signature scheme [3] forms one the most basic usages of random oracles. It works with a family F of trapdoor permutations (TDP), where the signature of m is computed as f −1 (h(m)) (here f ∈R F and h is modelled as a random oracle). It is known to be existentially unforgeable for any TDP family F [3], although a much tighter security reduction is known for a restrictive class of TDP’s [10, 14] — namely, those induced by a family of clawfree permutations (CFP) pairs. The latter result was shown [11] to match the best possible “blackbox ” security reduction in the random oracle model, irrespective of the TDP family F (e.g., RSA) one might use. In this work we investigate the question if it is possible to instantiate the random oracle h with a “real ” family of hash functions H such that the corresponding schemes can be proven secure in the standard model, under some natural assumption on the family F. Our main result rules out the existence of such instantiations for any assumption on F which (1) is satisfied by a family of random permutations; and (2) does not allow the attacker to invert f ∈R F on an apriori unbounded number of points. Moreover, this holds even if the choice of H can arbitrarily depend on f. As an immediate corollary, we rule out instantiating FDH based on general clawfree permutations, which shows that in order to prove the security of FDH in the standard model one must utilize significantly more structure on F than what is sufficient for the best proof of security in the random oracle model. 1
A “proofreading ” of some issues in cryptography
"... Abstract. In this paper, we identify some issues in the interplay between practice and theory in cryptography, issues that have repeatedly appeared in different incarnations over the years. These issues are related to fundamental concepts in the field, e.g., to what extent we can prove that a system ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract. In this paper, we identify some issues in the interplay between practice and theory in cryptography, issues that have repeatedly appeared in different incarnations over the years. These issues are related to fundamental concepts in the field, e.g., to what extent we can prove that a system is secure and what theoretic results on security mean for practical applications. We argue that several such issues are often overlooked or misunderstood, and that it may be very productive if both theoreticians and practitioners think more consciously about these issues and act accordingly. 1
A new Design Criteria for HashFunctions
"... Abstract. The most common way of constructing a hash function (e.g., SHA1) is to iterate a compression function on the input message. The compression function is usually designed from scratch or made out of a blockcipher. In this paper, we introduce a new security notion for hashfunctions, strong ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract. The most common way of constructing a hash function (e.g., SHA1) is to iterate a compression function on the input message. The compression function is usually designed from scratch or made out of a blockcipher. In this paper, we introduce a new security notion for hashfunctions, stronger than collisionresistance. Under this notion, the arbitrary length hash function H must behave as a random oracle when the fixedlength building block is viewed as an ideal primitive. This enables to eliminate all possible generic attacks against iterative hashfunctions. In this paper, we show that the current design principle behind hash functions such as SHA1 and MD5 — the (strengthened) MerkleDamg˚ard transformation — does not satisfy this security notion. We provide several constructions that provably satisfy this notion; those new constructions introduce minimal changes to the plain MerkleDamg˚ard construction and are easily implementable in practice. This paper is a modified version of a paper to appear at Crypto 2005. 1
MerkleDamgºard Revisited: how to Construct a Hash Function
"... Abstract. The most common way of constructing a hash function (e.g., SHA1) is to iterate a compression function on the input message. The compression function is usually designed from scratch or made out of a blockcipher. In this paper, we introduce a new security notion for hashfunctions, strong ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract. The most common way of constructing a hash function (e.g., SHA1) is to iterate a compression function on the input message. The compression function is usually designed from scratch or made out of a blockcipher. In this paper, we introduce a new security notion for hashfunctions, stronger than collisionresistance. Under this notion, the arbitrary length hash function H must behave as a random oracle when the ¯xedlength building block is viewed as a random oracle or an ideal blockcipher. The key property is that if a particular construction meets this de¯nition, then any cryptosystem proven secure assuming H is a random oracle remains secure if one plugs in this construction (still assuming that the underlying ¯xedlength primitive is ideal). In this paper, we show that the current design principle behind hash functions such as SHA1 and MD5  the (strengthened) MerkleDamgºard transformation  does not satisfy this security notion. We provide several constructions that provably satisfy this notion; those new constructions introduce minimal changes to the plain MerkleDamgºard construction and are easily implementable in practice. 1