Results 1  10
of
17
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 74 (8 self)
 Add to MetaCart
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.
Hash Functions Based on Block Ciphers
 Proc. of EUROCRYPT 92
, 1993
"... . Iterated hash functions based on block ciphers are treated. Five attacks on an iterated hash function and on its round function are formulated. The wisdom of strengthening such hash functions by constraining the last block of the message to be hashed is stressed. Schemes for constructing mbit ..."
Abstract

Cited by 53 (7 self)
 Add to MetaCart
. Iterated hash functions based on block ciphers are treated. Five attacks on an iterated hash function and on its round function are formulated. The wisdom of strengthening such hash functions by constraining the last block of the message to be hashed is stressed. Schemes for constructing mbit and 2mbit hash round functions from mbit block ciphers are studied. A principle is formalized for evaluating the strength of hash round functions, viz., that applying computationally simple #in both directions# invertible transformations to the input and output of a hash round function yields a new hash round function with the same security. By applying this principle, four attacks on three previously proposed 2mbit hash round functions are formulated. Finally, three new hash round functions based on an mbit block cipher with a 2mbit key are proposed. 1 Introduction This paper is intended to provide a rather rounded treatment of hash functions that are obtained by iterati...
On the impossibility of highlyefficient blockcipherbased hash functions
 in Advances in Cryptology—EUROCRYPT 2005
, 2005
"... Abstract. Fix a small, nonempty set of blockcipher keys K. We say a blockcipherbased hash function is highlyefficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a key from K. Although a few highlyefficient constructions have been propose ..."
Abstract

Cited by 26 (3 self)
 Add to MetaCart
Abstract. Fix a small, nonempty set of blockcipher keys K. We say a blockcipherbased hash function is highlyefficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a key from K. Although a few highlyefficient constructions have been proposed, no one has been able to prove their security. In this paper we prove, in the idealcipher model, that it is impossible to construct a highlyefficient iterated blockcipherbased hash function that is provably secure. Our result implies, in particular, that the Tweakable Chain Hash (TCH) construction suggested by Liskov, Rivest, and Wagner [7] is not correct under an instantiation suggested for this construction, nor can TCH be correctly instantiated by any other efficient means.
Formalizing human ignorance: Collisionresistant hashing without the keys
 In Proc. Vietcrypt ’06
, 2006
"... Abstract. There is a foundational problem involving collisionresistant hashfunctions: common constructions are keyless, but formal definitions are keyed. The discrepancy stems from the fact that a function H: {0, 1} ∗ → {0, 1} n always admits an efficient collisionfinding algorithm, it’s just t ..."
Abstract

Cited by 22 (0 self)
 Add to MetaCart
Abstract. There is a foundational problem involving collisionresistant hashfunctions: common constructions are keyless, but formal definitions are keyed. The discrepancy stems from the fact that a function H: {0, 1} ∗ → {0, 1} n always admits an efficient collisionfinding algorithm, it’s just that us human beings might be unable to write the program down. We explain a simple way to sidestep this difficulty that avoids having to key our hash functions. The idea is to state theorems in a way that prescribes an explicitlygiven reduction, normally a blackbox one. We illustrate this approach using wellknown examples involving digital signatures, pseudorandom functions, and the MerkleDamg˚ard construction. Key words. Collisionfree hash function, Collisionintractable hash function, Collisionresistant hash function, Cryptographic hash function, Provable security. 1
M.: Indifferentiable security analysis of popular hash functions with prefixfree padding
 ASIACRYPT 2006. LNCS
, 2006
"... Abstract. Understanding what construction strategy has a chance to be a good hash function is extremely important nowadays. In TCC’04, Maurer et al. [13] introduced the notion of indifferentiability as a generalization of the concept of the indistinguishability of two systems. In Crypto’2005, Coron ..."
Abstract

Cited by 13 (1 self)
 Add to MetaCart
Abstract. Understanding what construction strategy has a chance to be a good hash function is extremely important nowadays. In TCC’04, Maurer et al. [13] introduced the notion of indifferentiability as a generalization of the concept of the indistinguishability of two systems. In Crypto’2005, Coron et al. [5] suggested to employ indifferentiability in generic analysis of hash functions and started by suggesting four constructions which enable eliminating all possible generic attacks against iterative hash functions. In this paper we continue this initial suggestion and we give a formal proof of indifferentiability and indifferentiable attack for prefixfree MD hash functions (for single block length (SBL) hash and also some double block length (DBL) constructions) in the random oracle model and in the ideal cipher model. In particular, we observe that there are sixteen PGV hash functions (with prefixfree padding) which are indifferentiable from random oracle model in the ideal cipher model. 1
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
Towards Secure and Fast Hash Functions
, 1999
"... this paper [15], [16] (m, 2m) block cipher this paper this paper Suppose that ..."
Abstract

Cited by 10 (0 self)
 Add to MetaCart
this paper [15], [16] (m, 2m) block cipher this paper this paper Suppose that
On the Impossibility of Highly Efficient BlockcipherBased Hash Functions
, 2004
"... We say a blockcipherbased hash function is highly efficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a single underlying key. Although a few highly efficient constructions have been proposed, no one has been able to prove their security. ..."
Abstract

Cited by 7 (3 self)
 Add to MetaCart
We say a blockcipherbased hash function is highly efficient if it makes exactly one blockcipher call for each message block hashed, and all blockcipher calls use a single underlying key. Although a few highly efficient constructions have been proposed, no one has been able to prove their security. In this paper we prove, in the blackbox model, that it is impossible to construct a highly efficient blockcipherbased hash function which is provably secure. Our result implies, in particular, that the Tweakable Chain Hash (TCH) construction suggested by Liskov, Rivest, and Wagner [3] is not correct under an instantiation suggested for this construction, nor can TCH be correctly instantiated by any other efficient means.
A Synthetic Indifferentiability Analysis of Some BlockCipherBased Hash Functions
, 2007
"... At ASIACRYPT’06, Chang et al. analyzed the indifferentiability of some popular hash functions based on block ciphers, namely, the twenty collision resistant PGV, the MDC2 and the PBGV hash functions, etc. In particular, two indifferentiable attacks were presented on the four of the twenty collision ..."
Abstract

Cited by 5 (2 self)
 Add to MetaCart
At ASIACRYPT’06, Chang et al. analyzed the indifferentiability of some popular hash functions based on block ciphers, namely, the twenty collision resistant PGV, the MDC2 and the PBGV hash functions, etc. In particular, two indifferentiable attacks were presented on the four of the twenty collision resistant PGV and the PBGV hash functions with the prefixfree padding. In this article, a synthetic indifferentiability analysis of some blockcipherbased hash functions is considered. First, a more precise definition is proposed on the indifferentiability adversary in blockcipherbased hash functions. Next, the advantage of indifferentiability is extended by considering whether the hash function is keyed or not. Finally, a limitation is observed in Chang et al.’s indifferentiable attacks on the four PGV and the PBGV hash functions. The formal proofs show the fact that those hash functions are indifferentiable from a random oracle in the ideal cipher model with the prefixfree padding, the NMAC/HMAC and the chop construction.
Efficient Garbling from a FixedKey Blockcipher
, 2013
"... Abstract. We advocate schemes based on fixedkey AES as the best route to highly efficient circuitgarbling. We provide such schemes making only one AES call per garbledgate evaluation. On the theoretical side, we justify the security of these methods in the randompermutation model, where parties h ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
Abstract. We advocate schemes based on fixedkey AES as the best route to highly efficient circuitgarbling. We provide such schemes making only one AES call per garbledgate evaluation. On the theoretical side, we justify the security of these methods in the randompermutation model, where parties have access to a public random permutation. On the practical side, we provide the JustGarble system, which implements our schemes. JustGarble evaluates moderatesized garbledcircuits at an