5
$\begingroup$

So far as I can find, every method better at producing hash collisions in cryptographic hashes than generic collision search involves finding some metric for the distance between two messages' hashes and calculating alterations to each that will iteratively reduce that distance.

And further, unless I'm misreading it, none of the existing attacks is a "forgery" attack, allowing the attacker to converge on a known hash; they all work by iteratively altering multiple messages, eventually arriving at a set that all have some shared but unpredictable result.

Are these true? If so,

  • wouldn't $\mathcal H^\prime(m) = \mathcal H(\mathcal H(m)|m)$ be completely immune to current attacks (at the cost of giving up on one-pass hashing)?

@RickyDemer pointed out in comments that available parallelism makes even random-walk search formidable, and it does seem to me that while appending the full hash forces full recalculation at each iteration, stripping that advantage isn't on average going to claw back more than say eight bits of strength.... though I suppose recursing the construction until at least a certain number of hash blocks have been processed could slow down attackers arbitrarily.

So, just for fun, $$\mathcal H^0_H(m) = H(m)$$ $$ \mathcal H^n_H(m) = H(\mathcal H^{n-1}_H(m)|m)$$ $$|\mathcal H^n_H(m)|=1+n\cdot|m|$$ (with $|m|$ expressed in units of $H$'s block size) $$ \mathcal{\bar H}^e_H(m)=\mathcal H^n_H(m): \log_2|\mathcal H^{n-1}_H(m)| <e \le \log_2 |\mathcal H^n_H(m)|$$

So $\mathcal {\bar H}^{16}_{\rm SHA1}$ would be $\mathcal H^n_{\rm SHA1}$, $n$ large enough that at least $2^{16}$ additional blocks were hashed.

Leaving the question after accounting for his observation:

  • would $\mathcal {\bar H}^e_H$ be immune to current attacks (at the cost of giving up on one-pass hashing) even in the face of an attacker willing to throw $2^e$ parallel devices at it?
Improve this question
$\endgroup$
7
  • $\begingroup$ I think the generic attack doesn't involve that. $\;$ $\endgroup$ – user991 May 11 '14 at 17:46
  • $\begingroup$ @RickyDemer Parallel brute force is still brute force, though, isn't it? Doesn't a method have to be faster than brute force before the method itself is regarded as an attack? $\endgroup$ – jthill May 11 '14 at 17:59
  • $\begingroup$ Even if so, the paper I linked to gives a method that I think doesn't use any metric as you described. $\hspace{.36 in}$ $\endgroup$ – user991 May 11 '14 at 18:11
  • 3
    $\begingroup$ "exhaustive search" $\: \mapsto \:$ "[generic collision search](http://people.scs.carleton.ca/~paulv/papers/JoC97.pdf)" $\hspace{1.8 in}$ $\endgroup$ – user991 May 11 '14 at 21:31
  • $\begingroup$ Hm. Always assuming I'm reading this right (I think I understand...) -- although this does get much better performance than a naive exhaustive search by being massively parallelizable and clever with its iteration and sequencing, it's still exhaustive search of the hash result space -- $g$ in both sect. 4.1 and sect. 5.2 iterates on $R$, the hash result (edit: the cleverness in sequencing not improving the likelihood of encountering a collision early, only enabling the parallelism). Is this incorrect or otherwise irrelevant here? $\endgroup$ – jthill May 11 '14 at 23:53
3
$\begingroup$

Your scheme is twice as slow as the original hash function. If you were going to accept such a huge performance penalty, you'd be better off just picking a new hash function that (you trust) isn't broken.

Also, it's not clear to me how much security your construction actually adds. I don't immediately see a proof that it is secure even if the compression function has some problems. I'm not even sure how one would formalize this. We'd have to assume something about the compression function, as you can't get something from nothing; but it's not clear what minimal assumptions about the compression function are sufficient to ensure that your construction is secure.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Near as I can tell, the Joux construction is built on a (reasonably) posited machine to produce collisions on $f(IV,B_n)$. But that machine is useless with $\mathcal H$ as above, as there are at least two IVs for each block, all but one of them completely unpredictable. Am I missing something fundamental here? From Kelsey and Schneier's paper, "In Joux's technique, a sequence of single-message-block collisions is found, and then pasted together to provide a large number of different messages of equal length that lead to the same hash value." -- and that's what I believe just won't work here. $\endgroup$ – jthill May 13 '14 at 1:59
  • $\begingroup$ @jthill, you're right. I don't have a working attack with Joux multicollisions. I'm still skeptical. Without a proof, I don't know how we could be confident that this construction adds any security (Joux multicollisions are an example of something that showed simple intuitions regarding techniques for strengthening hashes can be very wrong). I'm not at all confident that this construction cannot be attacked -- maybe it does have nice security properties, but I think we'd need a proof before we could trust that it does. $\endgroup$ – D.W. May 13 '14 at 5:52
  • $\begingroup$ Thank you. I see your point about the speed, to add a 40-bit buffer against parallel search, the most efficient way would be to switch to an 80-bit-longer hashcode. Re proof, this am I ran across "we are unable to prove that, perhaps tomorrow, some novel and devastating attack will not show it to be critically insecure. Every hash function will necessarily contain such a component, at least until a proof that P!=NP is found, and possibly long after that." ... "will necessarily"? $\endgroup$ – jthill May 13 '14 at 15:17
  • $\begingroup$ That said, though, and acknowledging (the obvious,) that I'm a complete tyro at this, isn't it enough to say that $\mathcal H^\prime$ is trivially at least as secure as the underlying hash function $H$, and is additionally immune to any attack based on finding single-block collisions with a known IV? I think it's reasonable to presume a block function "sufficiently complex that it behaves like a random mapping" $\endgroup$ – jthill May 13 '14 at 16:16
  • $\begingroup$ Well, it appears I may have just reinvented HMAC with feedback-derived password. Might as well just use that. $\endgroup$ – jthill May 14 '14 at 23:54
3
$\begingroup$

This is sometimes called hash-twice in the literature. Obviously it can't do better than $n$-bit (second-)preimage resistance and $n/2$-bit collision resistance, but it can do worse. It has long been a folklore construction; it seems to have been first formally analyzed in

Elena Andreeva, Charles Bouillaguet, Orr Dunkelman, and John Kelsey, ‘Herding, Second Preimage and Trojan Message Attacks beyond Merkle-Damgård’, in Michael J. Jacobson, Jr., Vincent Rijmen, and Reihaneh Safavi-Naini, eds., Selected Areas in Cryptography—SAC 2009, Springer LNCS 5867, pp. 393–414,

and generic attacks on the construction were improved in

Zhenzhen Bao, Itai Dinur, Jian Guo, Gaëtan Leurent, and Lei Wang, ‘Generic Attacks on Hash Combiners’, Journal of Cryptology 145, 2019, pp. 1–82 (preprint).

Maybe it thwarts MD5 collision attacks, but if you can replace the hash function, you're probably better off switching to an unbroken hash rather than this generic construction which isn't as good.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Would you mind giving a quick overview of how much worse (if applicable) the construction is than the generic one based on the two given references? $\endgroup$ – SEJPM♦ Sep 21 '19 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.