SEO

On Fri, Aug 25, 2006 at 09:31:59PM +0200, Dries Schellekens wrote:
> Marc Bevand wrote:
>
> >| Finding a collision for both MD5 and SHA-1 at the same time is
> >| completely improbable.
> >
> >Finding a collision for SHA-1 was also deemed completely improbable ten
> >years ago. However nowadays the attack seems very probable.
> >
> >My point is, finding a collision for both MD5 and SHA-1 will eventually
> >get accomplished some day. If it was really considered improbable, then
> >I suggest cryptographers stop researching secure hashing algorithms and
> >start using the hash function H(x) = MD5(x) . SHA1(x), where '.' is the
> >concatenation operator.
>
> The performance of this hash function will be poor.
>
> All this is irrelevant for the application we are looking at, namely
> OpenBSD ports. As kjell pointed out, you need to perform a second
> preimage attack and not a collision attack. Please read
> http://www.ecrypt.eu.org/documents/S...H_STMT-1.1.pdf to
> clearly understand the difference.
>
> All the attacks that have been found so far are collision attacks, not
> second preimage attacks. Therefore, these attacks mainly have
> implications on digital signatures.
>
> If an attacker succeeds in finding a second preimage for a certain hash
> value (of a tarball you want to download), he will also need to
> construct a corrupted compressed tarball with the second preimage. Not
> so simple either.

Actually, collision attacks are slightly relevant in some scenarios.

Just think about it. The known collision attacks for SHA1 rely on being
able to set about 1024 bytes of contiguous data arbitrarily.

If you assume the person distributing the software is the bad guy, there
usually is enough room in any distfile for padding with random stuff.
(heck, just include a catalog for a translation to basque or zulu).

Then the attacker can distribute a clean file for a while, then silently
replace it with the modified file, and you won't notice.

But there are actual reasons why this scenario is not of much relevance.
The most important being collaborative: a lot of projects use the same
distfile with distinct hashes. So, in effect, you have to break all hashes
at the same time to not be noticed...

The infrastructure in the ports tree was designed to counter this problem:
we provide all three hashes, rmd160, sha1, md5...

Just set your preferred cipher randomly. Each time you build a package, you're
running one of these checks. If you notice anything suspicious tell us.
If you have several build machines, set them to distinct ciphers.

Do you really think actual problems will survive this kind of checking ?


Personally, I'm much more worried about gnu shit.
Loads and loads of generated files.

Who checks configure files ?
Who checks Makefile.in files ?
Who checks bison generated files ?
Who checks libtool templates ?

Some time ago, a minor update to libdvdread resulted in >10000 lines of diff !
2 lines of actual code, the rest was just libtool/autoconf/automake version
updates.

There is a window of opportunity there: someone can replace an archive of
new software before it even gets checksummed.

Adding more checks to distinfo won't close that window.

That's one reason why it's vitally important to make sure source distributors
do their job and update version numbers each time they make an update.
(Helllooo ImageMagick dudes).