[pacman-dev] MD5/SHA* why?

[Xavier]

2007/7/3, Jeff Mickey <jeff at archlinux.org>:
> On 7/3/07, Mateusz Jedrasik <m.jedrasik at gmail.com> wrote:
> > Tuesday 03 of July 2007 21:40:17 Andrew Fyfe napisał(a):
> > > I asked this question a while ago about makepkg now I'm asking about
> > > pacman... why do we need support for multiple checksum types? What's
> > > wrong with md5?
>
> The problem with MD5 (and recently SHA1) is that you can find
> collisions relatively quickly on a powerful machine (under a day in
> some cases).  Thus if you found the correct collision that actually
> was a valid tarball, that had valid files in it, and one of those
> files had something malicious in it, you would be in trouble.  I mean,
> the chances are close to zero, but md5 has gotten a lot of press on
> how "crackable" it is.  SHA1 is crackable as well, thought not as
> easily.
>

Note what Jason said there :
http://www.archlinux.org/pipermail/pacman-dev/2006-October/005990.html
"Most of the ones I've seen talked about creating md5 collisions between
two files, not creating a file with the same md5 as another file
(there's a distinction)."

The numbers you gave are for which case ?

But even without talking about that, like you already said, it looks
indeed very unlikely this could be exploitable...

> Now put BOTH sums in your PKGBUILD.  Now some third party would have
> to find all the collisions for MD5 and SHA1, make sure they create the
> same sums as those in the package, and then they would have to see if
> that was even any data that could be used for something malicious.
>
> I suggest using both MD5 and SHA1.  I seriously doubt there is a
> single situation where this would not be enough for validating the
> package.

Heh, we already seriously doubt there is a single situation where
MD5 wouldn't be enough, so what does this add exactly ?
If we are going to be completely paranoid, then why not using ONE
algorithm that hasn't been cracked yet ?

>
> Though I think we should move to signing our packages, so we actually
> have security along with validation...
>

Now that's probably a better suggestion, and there is at least already
a FR for it :)
http://bugs.archlinux.org/task/5331