Re: Call to atention about using hash functions as content indexers (SCM saga)

[Eric Rannaud <eric.rannaud@ens.fr>]

On Thu, 2005-04-14 at 01:30 -0700, Andy Isaacson wrote:
> In particular, your defense here is specious.  I agree that second
> preimage is an unmanagably large problem for SHA1 for the forseeable
> future (say, 8 years out), but collision results almost always result in
> partially-controlled attack text.  So I can choose my nefarious content,
> and encode the collision entropy in non-operative text (a C comment, for
> example).

Everything you said is fair enough, and I do agree with this argument in
the context of authentication: that is if you expect an attack (even if
a chunk of non-operative bytes won't go unnoticed for long in a the
kernel tree, but that's not the point).

But the original post of Pedro was, I think, about collisions occurring
'randomly' between two genuine modifications of a source file. In
particular, the paper that was linked to by Pedro is concerned with this
kind of unexpected collisions, i.e. about integrity in normal operation
and not about security (btw, this paper seems kind of bogus to me
because it never specifies the hash function in use).

I took the example of this attack against SHA-1 only to illustrate that
*even* if you try to find a collision, you just can't find one (at least
these days).
>From which I think it is fair to say that such a collision won't happen
between two different versions of the same file, during the normal
process of revision.

I mean, if in the normal revision process of the kernel, a SHA-1
collision was to be found, by chance, who gets to publish the paper at
the next Crypto conference?

However, if we consider the case of an attack, well, that's different.
And you're right.

    /er.
-- 
http://www.eleves.ens.fr/home/rannaud/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/