Results 1  10
of
52
Salvaging MerkleDamg˚ard for Practical Applications
, 2009
"... Many cryptographic applications of hash functions are analyzed in the random oracle model. Unfortunately, most concrete hash functions, including the SHA family, use the iterative (strengthened) MerkleDamg˚ard transform applied to a corresponding compression function. Moreover, it is well known tha ..."
Abstract

Cited by 20 (2 self)
 Add to MetaCart
Many cryptographic applications of hash functions are analyzed in the random oracle model. Unfortunately, most concrete hash functions, including the SHA family, use the iterative (strengthened) MerkleDamg˚ard transform applied to a corresponding compression function. Moreover, it is well known that the resulting “structured ” hash function cannot be generically used as a random oracle, even if the compression function is assumed to be ideal. This leaves a large disconnect between theory and practice: although no attack is known for many concrete applications utilizing existing (MerkleDamg˚ard based) hash functions, there is no security guarantee either, even by idealizing the compression function. Motivated by this question, we initiate a rigorous and modular study of developing new notions of (still idealized) hash functions which would be (a) natural and elegant; (b) sufficient for arguing security of important applications; and (c) provably met by the (strengthened) MerkleDamg˚ard transform, applied to a “strong enough ” compression function. In particular, we show that a fixedlength compressing random oracle, as well as the currently used DaviesMeyer compression function (the latter analyzed in the ideal cipher model) are “strong enough ” for the two specific weakenings of the random oracle that we develop. These weaker notions, described below, are quite natural and should be interesting in their own right: • Preimage Aware Functions. Roughly, if an attacker found a “later useful ” output y of the function, then it must
Constructing cryptographic hash functions from fixedkey blockciphers. Full version of this paper
, 2008
"... Abstract. We propose a family of compression functions built from fixedkey blockciphers and investigate their collision and preimage security in the idealcipher model. The constructions have security approaching and in many cases equaling the security upper bounds found in previous work of the aut ..."
Abstract

Cited by 19 (5 self)
 Add to MetaCart
Abstract. We propose a family of compression functions built from fixedkey blockciphers and investigate their collision and preimage security in the idealcipher model. The constructions have security approaching and in many cases equaling the security upper bounds found in previous work of the authors [24]. In particular, we describe a 2nbit to nbit compression function using three nbit permutation calls that has collision security N 0.5,whereN =2 n, and we describe 3nbit to 2nbit compression functions using five and six permutation calls and having collision security of at least N 0.55 and N 0.63. Key words: blockcipherbased hashing, collisionresistant hashing, compression functions, cryptographic hash functions, idealcipher model. 1
Building a collisionresistant compression function from noncompressing primitives
 In ICALP 2008, Part II
, 2008
"... Abstract. We consider how to build an efficient compression function from a small number of random, noncompressing primitives. Our main goal is to achieve a level of collision resistance as close as possible to the optimal birthday bound. We present a 2nton bit compression function based on three ..."
Abstract

Cited by 15 (3 self)
 Add to MetaCart
Abstract. We consider how to build an efficient compression function from a small number of random, noncompressing primitives. Our main goal is to achieve a level of collision resistance as close as possible to the optimal birthday bound. We present a 2nton bit compression function based on three independent nton bit random functions, each called only once. We show that if the three random functions are treated as black boxes then finding collisions requires Θ(2 n/2 /n c) queries for c ≈ 1. This result remains valid if two of the three random functions are replaced by a fixedkey ideal cipher in DaviesMeyer mode (i.e., EK(x) ⊕ x for permutation EK). We also give a heuristic, backed by experimental results, suggesting that the security loss is at most four bits for block sizes up to 256 bits. We believe this is the best result to date on the matter of building a collisionresistant compression function from noncompressing functions. It also relates to an open question from Black et al. (Eurocrypt’05), who showed that compression functions that invoke a single noncompressing random function cannot suffice. We also explore the relationship of our problem with that of doubling the output of a hash function and we show how our compression function can be used to double the output length of ideal hashes.
On the indifferentiability of the Grøstl hash function
 In SCN ’10, LNCS
, 2010
"... Abstract. The notion of indifferentiability, introduced by Maurer et al., is an important criterion for the security of hash functions. Concretely, it ensures that a hash function has no structural design flaws and thus guarantees security against generic attacks up to the proven bounds. In this wor ..."
Abstract

Cited by 14 (5 self)
 Add to MetaCart
Abstract. The notion of indifferentiability, introduced by Maurer et al., is an important criterion for the security of hash functions. Concretely, it ensures that a hash function has no structural design flaws and thus guarantees security against generic attacks up to the proven bounds. In this work we prove the indifferentiability of Grøstl, a second round SHA3 hash function candidate. Grøstl combines characteristics of the widepipe and chopMerkleDamg˚ard iterations and uses two distinct permutations P and Q internally. Under the assumption that P and Q are random lbit permutations, where l is the iterated state size of Grøstl, we prove that the advantage of a distinguisher to differentiate Grøstl from a random oracle is upper bounded by O((Kq) 4 /2 l), where the distinguisher makes at most q queries of length at most K blocks. This result implies that Grøstl behaves like a random oracle up to q = O(2 n/2) queries, where n is the output size. Furthermore, we show that the output transformation of Grøstl, as well as ‘Grøstail ’ (the composition of the final compression function and the output transformation), are clearly differentiable from a random oracle. This rules out indifferentiability proofs which rely on the idealness of the final state transformation. 1
A Framework for Iterative Hash Functions: HAIFA
 In Proceedings of Second NIST Cryptographic Hash Workshop, 2006 . Available from: www.csrc.nist.gov/pki/HashWorkshop/2006/program_2006.htm
"... Abstract. Since the seminal works of Merkle and Damg˚ard on the iteration of compression functions, hash functions were built from compression functions using the MerkleDamg˚ard construction. Recently, several flaws in this construction were identified, allowing for second preimage attacks and cho ..."
Abstract

Cited by 14 (0 self)
 Add to MetaCart
Abstract. Since the seminal works of Merkle and Damg˚ard on the iteration of compression functions, hash functions were built from compression functions using the MerkleDamg˚ard construction. Recently, several flaws in this construction were identified, allowing for second preimage attacks and chosen target preimage attacks on such hash functions even when the underlying compression functions are secure. In this paper we propose the HAsh Iterative FrAmework (HAIFA). Our framework can fix many of the flaws while supporting several additional properties such as defining families of hash functions and supporting variable hash size. HAIFA allows for an online computation of the hash function in one pass with a fixed amount of memory independently of the size of the message. Besides our proposal, the recent attacks initiated research on the way compression functions are to be iterated. We show that most recent proposals such as randomized hashing, the enveloped MerkleDamg˚ard, and the RMC and ROX modes can be all be instantiated as part of the HAsh
Hash Functions in the DedicatedKey Setting: Design Choices and MPP Transforms
 In ICALP ’07, volume 4596 of LNCS
, 2007
"... In the dedicatedkey setting, one starts with a compression function f: {0, 1} k ×{0, 1} n+d → {0, 1} n and builds a family of hash functions H f: K × M → {0, 1} n indexed by a key space K. This is different from the more traditional design approach used to build hash functions such as MD5 or SHA1, ..."
Abstract

Cited by 13 (1 self)
 Add to MetaCart
In the dedicatedkey setting, one starts with a compression function f: {0, 1} k ×{0, 1} n+d → {0, 1} n and builds a family of hash functions H f: K × M → {0, 1} n indexed by a key space K. This is different from the more traditional design approach used to build hash functions such as MD5 or SHA1, in which compression functions and hash functions do not have dedicated key inputs. We explore the benefits and drawbacks of building hash functions in the dedicatedkey setting (as compared to the more traditional approach), highlighting several unique features of the former. Should one choose to build hash functions in the dedicatedkey setting, we suggest utilizing multipropertypreserving (MPP) domain extension transforms. We analyze seven existing dedicatedkey transforms with regard to the MPP goal and propose two simple
How to Build a Hash Function from any CollisionResistant Function
, 2007
"... Recent collisionfinding attacks against hash functions such as MD5 and SHA1 motivate the use of provably collisionresistant (CR) functions in their place. Finding a collision in a provably CR function implies the ability to solve some hard problem (e.g., factoring). Unfortunately, existing provab ..."
Abstract

Cited by 12 (3 self)
 Add to MetaCart
Recent collisionfinding attacks against hash functions such as MD5 and SHA1 motivate the use of provably collisionresistant (CR) functions in their place. Finding a collision in a provably CR function implies the ability to solve some hard problem (e.g., factoring). Unfortunately, existing provably CR functions make poor replacements for hash functions as they fail to deliver behaviors demanded by practical use. In particular, they are easily distinguished from a random oracle. We initiate an investigation into building hash functions from provably CR functions. As a method for achieving this, we present the MixCompressMix (MCM) construction; it envelopes any provably CR function H (with suitable regularity properties) between two injective “mixing” stages. The MCM construction simultaneously enjoys (1) provable collisionresistance in the standard model, and (2) indifferentiability from a monolithic random oracle when the mixing stages themselves are indifferentiable from a random oracle that observes injectivity. We instantiate our new design approach by specifying a blockcipherbased construction that
The SHAvite3 Hash Function
, 2009
"... In this document we present SHAvite3, a secure and efficient hash function based on the HAIFA construction and the AES building blocks. SHAvite3 uses a well understood set of primitives such as a Feistel block cipher which iterates a round function based on the AES round function. SHAvite3’s comp ..."
Abstract

Cited by 11 (1 self)
 Add to MetaCart
In this document we present SHAvite3, a secure and efficient hash function based on the HAIFA construction and the AES building blocks. SHAvite3 uses a well understood set of primitives such as a Feistel block cipher which iterates a round function based on the AES round function. SHAvite3’s compression functions are secure against cryptanalysis, while the selected mode of iteration offers maximal security against black box attacks on the hash function. SHAvite3 is both fast and resourceefficient, making it suitable for a wide range of environments, ranging from 8bit platforms to 64bit platforms (and beyond).
How Risky is the RandomOracle Model?
"... Abstract. RSAFDH and many other schemes secure in the RandomOracle Model (ROM) require a hash function with output size larger than standard sizes. We show that the randomoracle instantiations proposed in the literature for such cases are weaker than a random oracle, including the proposals by Be ..."
Abstract

Cited by 11 (0 self)
 Add to MetaCart
Abstract. RSAFDH and many other schemes secure in the RandomOracle Model (ROM) require a hash function with output size larger than standard sizes. We show that the randomoracle instantiations proposed in the literature for such cases are weaker than a random oracle, including the proposals by Bellare and Rogaway from 1993 and 1996, and the ones implicit in IEEE P1363 and PKCS standards: for instance, we obtain a practical preimage attack on BR93 for 1024bit digests (with complexity less than 2 30). Next, we study the security impact of hash function defects for ROM signatures. As an extreme case, we note that any hash collision would suffice to disclose the master key in the IDbased cryptosystem by Boneh et al. from FOCS ’07, and the secret key in the RabinWilliams signature for which Bernstein proved tight security at EUROCRYPT ’08. We also remark that collisions can be found as a precomputation for any instantiation of the ROM, and this violates the security definition of the scheme in the standard model. Hence, this gives an example of a natural scheme that is proven secure in the ROM but that in insecure for any instantiation by a single function. Interestingly, for both of these schemes, a slight modification can prevent these attacks, while preserving the ROM security result. We give evidence that in the case of RSA and Rabin/RabinWilliams, an appropriate PSS padding is more robust than all other paddings known. 1