The most common way of constructing a hash function (e.g., SHA-1) is to iterate a compression function on the input message. The compression function is usually designed from scratch or made out of a block-cipher. In this paper, we introduce a new security notion for hash-functions, stronger than collision-resistance. Under this notion, the arbitrary length hash function H must behave as a random oracle when the fixed-length building block is viewed as a random oracle or an ideal block-cipher. 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 fixed-length primitive is ideal). In this paper, we show that the current design principle behind hash functions such as SHA-1 and MD5 — the (strengthened) Merkle–Damgård 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 Merkle–Damgård construction and are easily implementable in practice.

In the dedicated-key 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 SHA-1, 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 dedicated-key setting (as compared to the more traditional approach), highlighting several unique features of the former. Should one choose to build hash functions in the dedicated-key setting, we suggest utilizing multi-property-preserving (MPP) domain extension transforms. We analyze seven existing dedicated-key transforms with regard to the MPP goal and propose two simple

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-collision attack, Kelsey and Schneier's second-preimage 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.

Abstract. We revisit the enhanced target collision resistance (eTCR) property as a newly emerged notion of security for dedicated-key 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 second-preimage resistance (Sec, aSec, eSec) and the three variants of preimage resistance (Pre, aPre, ePre). The results show that, for an arbitrary dedicated-key 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 Prefix-free) Merkle-Damg˚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.

♦ “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 SHA-1) to deploy protocol. ♦ Hope that nothing breaks down! Is SHA-1 Really Random? ♦ Is SHA-1 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

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 per-invocation 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 TBC-MAC construction (similar to CBC-MAC but chaining through the tweak), but leave open the question of its security. We close this question, both for TBC-MAC as a PRF and a MAC. Along the way, we find a nonce-based variant of TBC-MAC 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 input-length PRF with beyond birthday-bound security.