On Wed, Sep 16, 2015 at 1:38 AM, Stephan Beal <[email protected]> wrote:
> (i will naively assert) "impossible" that both the sha1 and md5 could
> both be made to match in a collision of a non-empty blob.
This might be too optimistic. According to Antoine Joux in
"Multicollisions in Iterated Hash Functions. Application to Cascaded
Constructions" [1]
A natural construction to build large hash values is to
concatenate several smaller
hashes. For example, given two hash functions F and G, it seems
reasonable given
a message M to form the large hash value (F(M)||G(M)). In this construction,
F and G can either be two completely different hash functions or
two slightly
different instances of the same hash function. If F and G are good
iterated hash
functions with no attack better than the generic birthday paradox attack, we
claim that the hash function F||G obtained by concatenating F and G is not
really more secure that F or G by itself. Moreover, this result
applies both to
collision resistance, preimage resistance and second preimage resistance.
[...]
Another generalization of the above attack is also worth noting. In [14],
B. Schneier described a different way of building a long hash from
a hash function
F. In this method, F(M) is concatenated with G(F(M)||M) (or G(M||F(M))).
At first view, this is more complicated than the F||G
construction. However, the
very same attack can be applied.
[...]
One can also study a related question, how does the security of
the concatenated
hash F||G behaves, when F and G have non-generic attacks better than
the birthday paradox collision search? In that case, can F||G be
significantly
more secure than the best of F and G?
[...] if G also admits a shortcut attack (as in section 3), it is
unclear whether
the two shortcut attacks may be used together to improve the composed attack
against F||G. Yet, some other type of attacks against G can be
integrated into a
better composed attack on F||G. ... Thus, it is safer to assume that F||G is
essentially as secure as the best of F and G, no more.
[1] http://link.springer.com/chapter/10.1007%2F978-3-540-28628-8_19
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
