Results 1 
9 of
9
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 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
Domain extension of public random functions: Beyond the birthday barrier
 In Advances in Cryptology – CRYPTO ’07 (2007), Lecture Notes in Computer Science
, 2007
"... Combined with the iterated constructions of Coron et al., our result leads to the first iterated construction of a hash function f0; 1g\Lambda ! f0; 1gn from a component function f0; 1gn! f0; 1gn that withstands all recently proposed generic attacks against iterated hash functions, like Joux's multi ..."
Abstract

Cited by 7 (1 self)
 Add to MetaCart
Combined with the iterated constructions of Coron et al., our result leads to the first iterated construction of a hash function f0; 1g\Lambda ! f0; 1gn from a component function f0; 1gn! f0; 1gn that withstands all recently proposed generic attacks against iterated hash functions, like Joux's multicollision attack, Kelsey and Schneier's secondpreimage attack, and Kelsey and Kohno's herding attacks. 1 Introduction 1.1 Secret vs. Public Random Functions Primitives that provide some form of randomness are of central importance in cryptography, both as a primitive assumed to be given (e.g. a secret key), and as a primitive constructed from a weaker one to "behave like " a certain ideal random primitive (e.g. a random function), according to some security notion.
A new mode of operation for block ciphers and lengthpreserving MACs
 of Lecture Notes in Computer Science
, 2008
"... Abstract. We propose a new mode of operation, enciphered CBC, for domain extension of lengthpreserving functions (like block ciphers), which is a variation on the popular CBC mode of operation. Our new mode is twice slower than CBC, but has many (propertypreserving) properties not enjoyed by CBC a ..."
Abstract

Cited by 5 (2 self)
 Add to MetaCart
Abstract. We propose a new mode of operation, enciphered CBC, for domain extension of lengthpreserving functions (like block ciphers), which is a variation on the popular CBC mode of operation. Our new mode is twice slower than CBC, but has many (propertypreserving) properties not enjoyed by CBC and other known modes. Most notably, it yields the first constantrate Variable Input Length (VIL) MAC from any length preserving Fixed Input Length (FIL) MAC. This answers the question of Dodis and Puniya from Eurocrypt 2007. Further, our mode is a secure domain extender for PRFs (with basically the same security as encrypted CBC). This provides a hedge against the security of the block cipher: if the block cipher is pseudorandom, one gets a VILPRF, while if it is “only ” unpredictable, one “at least ” gets a VILMAC. Additionally, our mode yields a VIL random oracle (and, hence, a collisionresistant hash function) when instantiated with lengthpreserving random functions, or even random permutations (which can be queried from both sides). This means that one does not have to rekey the block cipher during the computation, which was critically used in most previous constructions (analyzed in the ideal cipher model). 1
Multipropertypreserving Domain Extension Using Polynomialbased Modes of Operation
 Advances in cryptology – EUROcrYPT’10, LNCS
"... Abstract. In this paper, we propose a new doublepiped mode of operation for multipropertypreserving domain extension of MACs (message authentication codes), PRFs (pseudorandom functions) and PROs (pseudorandom oracles). Our mode of operation performs twice as fast as the original doublepiped mode ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
Abstract. In this paper, we propose a new doublepiped mode of operation for multipropertypreserving domain extension of MACs (message authentication codes), PRFs (pseudorandom functions) and PROs (pseudorandom oracles). Our mode of operation performs twice as fast as the original doublepiped mode of operation of Lucks [15] while providing comparable security. Our construction, which uses a class of polynomialbased compression functions proposed by Stam [22, 23], makes a single call to a 3nbit to nbit primitive at each iteration and uses a finalization function f2 at the last iteration, producing an nbit hash function H[f1, f2] satisfying the following properties. 1. H[f1, f2] is unforgeable up to O(2 n /n) query complexity as long as f1 and f2 are unforgeable. 2. H[f1, f2] is pseudorandom up to O(2 n /n) query complexity as long as f1 is unforgeable and f2 is pseudorandom. 3. H[f1, f2] is indifferentiable from a random oracle up to O(2 2n/3) query complexity as long as f1 and f2 are public random functions. To our knowledge, our result constitutes the first time O(2 n /n) unforgeability has been achieved using only an unforgeable primitive of nbit output length. (Yasuda showed unforgeability of O(2 5n/6) for Lucks ’ construction assuming an unforgeable primitive, but the analysis is suboptimal; in the appendix, we show how Yasuda’s bound can be improved to O(2 n).) In related work, we strengthen Stam’s collision resistance analysis of polynomialbased compression functions (showing that unforgeability of the primitive suffices) and discuss how to implement our mode by replacing f1 with a 2nbit key blockcipher in DaviesMeyer mode or by replacing f1 with the cascade of two 2nbit to nbit compression functions. 1
Y.: An Investigation of the Enhanced Target Collision Resistance Property for Hash Functions. Cryptology ePrint Archive, Report 2009/506
, 2009
"... Abstract. We revisit the enhanced target collision resistance (eTCR) property as a newly emerged notion of security for dedicatedkey hash functions, which has been put forth by Halevi and Krawczyk at CRYPTO’06, in conjunction with the Randomized Hashing mode to achieve this property. Our contributi ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
Abstract. We revisit the enhanced target collision resistance (eTCR) property as a newly emerged notion of security for dedicatedkey hash functions, which has been put forth by Halevi and Krawczyk at CRYPTO’06, in conjunction with the Randomized Hashing mode to achieve this property. Our contribution is twofold. Firstly, we provide a full picture of the relationships between eTCR and each of the seven security properties for a dedicatedkey hash function, considered by Rogaway and Shrimpton at FSE’04; namely, collision resistance (CR), the three variants of secondpreimage resistance (Sec, aSec, eSec) and the three variants of preimage resistance (Pre, aPre, ePre). The results show that, for an arbitrary dedicatedkey hash function, eTCR is not implied by any of these seven properties, and it can only imply three of the properties; namely, eSec (TCR), Sec, Pre. In the second part of the paper, we analyze the eTCR preservation capabilities of several domain extension transforms (a.k.a. modes of operation) for hash functions, including (Plain, Strengthened, and Prefixfree) MerkleDamg˚ard, Randomized Hashing, Shoup, Enveloped Shoup, XOR Linear Hash (XLH), and Linear Hash (LH). From this analysis it turns out that, with the exception of a nested variant of LH, none of the investigated transforms can preserve the eTCR property.
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
♦ “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
Tweakable Blockciphers with Beyond BirthdayBound Security
"... Abstract. Liskov, Rivest and Wagner formalized the tweakable blockcipher (TBC) primitive at CRYPTO’02. The typical recipe for instantiating a TBC is to start with a blockcipher, and then build up a construction that admits a tweak. Almost all such constructions enjoy provable security only to the bi ..."
Abstract
 Add to MetaCart
Abstract. Liskov, Rivest and Wagner formalized the tweakable blockcipher (TBC) primitive at CRYPTO’02. The typical recipe for instantiating a TBC is to start with a blockcipher, and then build up a construction that admits a tweak. Almost all such constructions enjoy provable security only to the birthday bound, and the one that does achieve security beyond the birthday bound (due to Minematsu) severely restricts the tweak size and requires perinvocation blockcipher rekeying. This paper gives the first TBC construction that simultaneously allows for arbitrarily “wide ” tweaks, does not rekey, and delivers provable security beyond the birthday bound. Our construction is built from a blockcipher and an ɛAXU2 hash function. As an application of the TBC primitive, LRW suggest the TBCMAC construction (similar to CBCMAC but chaining through the tweak), but leave open the question of its security. We close this question, both for TBCMAC as a PRF and a MAC. Along the way, we find a noncebased variant of TBCMAC that has a tight reduction to the security of the underlying TBC, and also displays graceful security degradation when nonces are misused. This result is interesting on its own, but it also serves as an application of our new TBC construction, ultimately giving a variable inputlength PRF with beyond birthdaybound security.
Cryptographic Hash Functions: Recent Design Trends and Security Notions ∗
"... Recent years have witnessed an exceptional research interest in cryptographic hash functions, especially after the popular attacks against MD5 and SHA1 in 2005. In 2007, the U.S. National Institute of Standards and Technology (NIST) has also significantly boosted this interest by announcing a publi ..."
Abstract
 Add to MetaCart
Recent years have witnessed an exceptional research interest in cryptographic hash functions, especially after the popular attacks against MD5 and SHA1 in 2005. In 2007, the U.S. National Institute of Standards and Technology (NIST) has also significantly boosted this interest by announcing a public competition to select the next hash function standard, to be named SHA3. Not surprisingly, the hash function literature has since been rapidly growing in an extremely fast pace. In this paper, we provide a comprehensive, uptodate discussion of the current state of the art of cryptographic hash functions security and design. We first discuss the various hash functions security properties and notions, then proceed to give an overview of how (and why) hash functions evolved over the years giving raise to the current diverse hash functions design approaches. A short version of this paper is in [1]. This version has been thoroughly extended, revised and updated. This