To Hash or Not to Hash Again? (In)Differentiability Results for $$H^2$$ and HMAC

Abstract

Abstract. We show that the second iterate H 2 (M ) = H(H(M )) of a random oracle H cannot achieve strong security in the sense of indifferentiability from a random oracle. We do so by proving that indifferentiability for H 2 holds only with poor concrete security by providing a lower bound (via an attack) and a matching upper bound (via a proof requiring new techniques) on the complexity of any successful simulator. We then investigate HMAC when it is used as a general-purpose hash function with arbitrary keys (and not as a MAC or PRF with uniform, secret keys). We uncover that HMAC's handling of keys gives rise to two types of weak key pairs. The first allows trivial attacks against its indifferentiability; the second gives rise to structural issues similar to that which ruled out strong indifferentiability bounds in the case of H 2 . However, such weak key pairs do not arise, as far as we know, in any deployed applications of HMAC. For example, using keys of any fixed length shorter than d − 1, where d is the block length in bits of the underlying hash function, completely avoids weak key pairs. We therefore conclude with a positive result: a proof that HMAC is indifferentiable from a RO (with standard, good bounds) when applications use keys of a fixed length less than d − 1.

Generic Related-Key Attacks for HMAC

“…In their analysis, in addition to several proof results, two types of weak keys called colliding key pairs and ambiguous key pairs were introduced for HMAC, which are closely related to our work. Indeed, regarding the colliding key pairs, exactly the same distinguisher is mentioned in both [13,12] and our article. The details of the distinguisher is shown in the last paragraph of Section 7.…”

“…After the publication of the conference version of this paper, we realized that the indifferentiability of HMAC was independently and at almost the same time studied by Dodis et al [13,12]. Their purpose is to study whether or not HMAC is indifferentiable from a keyed random oracle for distinguishers that can choose arbitrary keys.…”

“…The details of the distinguisher is shown in the last paragraph of Section 7. The ambiguous key pairs in [13,12] are the same as the key relation analyzed in this work, and both papers use the special computation structure that happens when using these key pairs. However, the analytic approach and the results are very different.…”

“…However, the analytic approach and the results are very different. [13,12] are under the indifferentiability framework where the key value is chosen and thus known by the adversary. Therefore, the adversary can know the internal state value and can observe that the computation chains followed by the two keys are shifted by exactly one invocation of the underlying hash function.…”

Generic Security of NMAC and HMAC with Input Whitening

“…While obtaining a non-tight birthday-type bound for NMAC/HMAC is feasible (for most key-length values, a bound follow directly from the indifferentiability analysis of [7]), proving tight bounds in terms of compression function and construction queries on the generic PRF security of NMAC/HMAC is a challenging open problem, on which little progress has been made. The main challenge is to understand how partial information in form of f-queries can help the attacker to break security (i.e., distinguish) in settings with q C 2 c/2 / √ , when the attack from [8] does not apply.…”