Time to replace MD5?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Time to replace MD5?

Touko Korpela
Debian Security Advisories currently contain MD5 checksums. As MD5 is no
longer strong enough, maybe it should be replaced by SHA1 or SHA256?


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Henrique de Moraes Holschuh
On Tue, 12 Jun 2007, Touko Korpela wrote:
> Debian Security Advisories currently contain MD5 checksums. As MD5 is no
> longer strong enough, maybe it should be replaced by SHA1 or SHA256?

When combined with size information AND the fact that it needs to be a valid
.deb archive, they are probably more than strong enough.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Joey Hess
In reply to this post by Touko Korpela
Touko Korpela wrote:
> Debian Security Advisories currently contain MD5 checksums. As MD5 is no
> longer strong enough, maybe it should be replaced by SHA1 or SHA256?

I don't understand why DSAs for etch include md5sums and manual upgrade
instructions at all. Apt can verify the checksum and gpg signature and
handle the upgrade after all, and probably more securely than the
average user following the manual instructions.

It may have made sense before we had signed Release files, (or perhaps
before we had apt :-), but it feels obsolete now. Note that DTSAs
already only include apt upgrade instructions.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Bernd Eckenfels
In article <[hidden email]> you wrote:
> I don't understand why DSAs for etch include md5sums and manual upgrade
> instructions at all. Apt can verify the checksum and gpg signature and
> handle the upgrade after all, and probably more securely than the
> average user following the manual instructions.

Because open source is all about choice. There might be admins using dpkg -i
or security officers who build their local mirrors manually.

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

dann frazier

On Wed, Jun 13, 2007 at 12:40:41AM +0200, Bernd Eckenfels wrote:
> In article <[hidden email]> you wrote:
> > I don't understand why DSAs for etch include md5sums and manual upgrade
> > instructions at all. Apt can verify the checksum and gpg signature and
> > handle the upgrade after all, and probably more securely than the
> > average user following the manual instructions.
>
> Because open source is all about choice. There might be admins using dpkg -i
> or security officers who build their local mirrors manually.

There may also be admins who prefer to use ar and run the maintainer
scripts by hand, and of course they are free to do so.

But, imo, Debian should document a single recommended procedure - and
direct execution of dpkg isn't something I'd recommend.

--
dann frazier


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Joey Hess
In reply to this post by Bernd Eckenfels
Bernd Eckenfels wrote:
> Because open source is all about choice.

So it's there because of a platitude?

> There might be admins using dpkg -i
> or security officers who build their local mirrors manually.

Then why don't we include md5sums and wget commands for all packages in
stable point release annoucements? Why not include them in major release
announcements too? Or are these things somehow less "all about choice"?

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Florian Weimer
In reply to this post by Henrique de Moraes Holschuh
* Henrique de Moraes Holschuh:

> On Tue, 12 Jun 2007, Touko Korpela wrote:
>> Debian Security Advisories currently contain MD5 checksums. As MD5 is no
>> longer strong enough, maybe it should be replaced by SHA1 or SHA256?
>
> When combined with size information

Size information doesn't buy you that much.

> AND the fact that it needs to be a valid .deb archive, they are
> probably more than strong enough.

That, and the "evil twin" package would have to be prepared by the
securty team as well, which isn't a relevant scenario (because they
could put a backdoor in the original without attacking the hash).


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Henrique de Moraes Holschuh
On Wed, 13 Jun 2007, Florian Weimer wrote:
> > On Tue, 12 Jun 2007, Touko Korpela wrote:
> >> Debian Security Advisories currently contain MD5 checksums. As MD5 is no
> >> longer strong enough, maybe it should be replaced by SHA1 or SHA256?
> >
> > When combined with size information
>
> Size information doesn't buy you that much.

When we are talking about a binary blob that matches the *same* md5sum? Yes,
it does.  Causing a MD5 colision with a message of the same size is far more
difficult.

> > AND the fact that it needs to be a valid .deb archive, they are
> > probably more than strong enough.
>
> That, and the "evil twin" package would have to be prepared by the
> securty team as well, which isn't a relevant scenario (because they

Would it?

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Mike Hommey
On Wed, Jun 13, 2007 at 10:37:26AM -0300, Henrique de Moraes Holschuh <[hidden email]> wrote:

> On Wed, 13 Jun 2007, Florian Weimer wrote:
> > > On Tue, 12 Jun 2007, Touko Korpela wrote:
> > >> Debian Security Advisories currently contain MD5 checksums. As MD5 is no
> > >> longer strong enough, maybe it should be replaced by SHA1 or SHA256?
> > >
> > > When combined with size information
> >
> > Size information doesn't buy you that much.
>
> When we are talking about a binary blob that matches the *same* md5sum? Yes,
> it does.  Causing a MD5 colision with a message of the same size is far more
> difficult.

Especially when it has to be a valid .deb file (which means an ar archive of
2 correctly gzipped tar files)

Mike


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Adrian von Bidder
In reply to this post by Touko Korpela
On Tuesday 12 June 2007 22.41:23 Touko Korpela wrote:
> Debian Security Advisories currently contain MD5 checksums. As MD5 is no
> longer strong enough, maybe it should be replaced by SHA1 or SHA256?

Strong enough for what?

You can get an md5 collision quite easily, but is 2nd preimage also broken?  
Note that you'd not only need a 2nd preimage for a given .deb, but the
resulting file also needs to have the same size as the original and be a
valid deb package.  quite a lot of conditions there.

cheers
-- vbi


--
OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481

signature.asc (262 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Giacomo Catenazzi
In reply to this post by Mike Hommey
Mike Hommey wrote:

> On Wed, Jun 13, 2007 at 10:37:26AM -0300, Henrique de Moraes Holschuh <[hidden email]> wrote:
>> On Wed, 13 Jun 2007, Florian Weimer wrote:
>>>> On Tue, 12 Jun 2007, Touko Korpela wrote:
>>>>> Debian Security Advisories currently contain MD5 checksums. As MD5 is no
>>>>> longer strong enough, maybe it should be replaced by SHA1 or SHA256?
>>>> When combined with size information
>>> Size information doesn't buy you that much.
>> When we are talking about a binary blob that matches the *same* md5sum? Yes,
>> it does.  Causing a MD5 colision with a message of the same size is far more
>> difficult.
>
> Especially when it has to be a valid .deb file (which means an ar archive of
> 2 correctly gzipped tar files)

But did somebody check if dpkg handle correctly (error) if there
are extra data after a gz or at the end of a dpkg?

ciao
        cate


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Florian Weimer
In reply to this post by Henrique de Moraes Holschuh
* Henrique de Moraes Holschuh:

>> Size information doesn't buy you that much.
>
> When we are talking about a binary blob that matches the *same* md5sum? Yes,
> it does.  Causing a MD5 colision with a message of the same size is far more
> difficult.

Oh, in this case, please show us a collision of two messages of 641
and 642 bytes. 8-)

AFAIK, the currently published attacks do not work well against the
final block with padding, so it's still not possible to change the
length.

>> > AND the fact that it needs to be a valid .deb archive, they are
>> > probably more than strong enough.
>>
>> That, and the "evil twin" package would have to be prepared by the
>> securty team as well, which isn't a relevant scenario (because they
>
> Would it?

With the currently published attacks, yes.  If significantly better
attacks appear, they might also apply to message digests in the same
family, so this is only a slightly convincing argument for replacing
MD5 with SHA-1 (or even SHA-256 ).  Actually, there isn't much Debian
can do, other than to wait.  We don't share many of the problems
because or protocols are proprietary, and we've got a working software
distribution process to end users.  Lots of other stuff (especially in
the IETF context, think appliances) needs to preserve interoperability
with other people's code, or can't be field-upgraded.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Steffen Schulz
In reply to this post by Florian Weimer
On 070613 at 10:43, Florian Weimer wrote:
> > AND the fact that it needs to be a valid .deb archive, they are
> > probably more than strong enough.

This is actually not much of a problem:

http://www.cits.rub.de/MD5Collisions/

One example how to create two files with same hash that act
differently. Should work with most active content.

Kaminsky did the same with self-extracting executables:

http://www.doxpara.com/md5_someday.pdf

> That, and the "evil twin" package would have to be prepared by the
> securty team as well, which isn't a relevant scenario (because they
> could put a backdoor in the original without attacking the hash).


So apt-get signatures use a secure hash function?

With the above results, it would be possible to officially distribute
nice behaving software but present specific targets with modified
packages that do evil.

Workaround would be to check two hashes(md5,sha1) or an XOR of them.


/pepe
--
       #
 (o_  #                                                +49/1781384223
 //\-x                                        gpg --recv-key A04D7875
 V_/_    Use the source, Tux!             mailto: [hidden email]


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Michael Stone-2
On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote:

>On 070613 at 10:43, Florian Weimer wrote:
>> > AND the fact that it needs to be a valid .deb archive, they are
>> > probably more than strong enough.
>
>This is actually not much of a problem:
>
>http://www.cits.rub.de/MD5Collisions/
>
>One example how to create two files with same hash that act
>differently. Should work with most active content.

Cool. So the security team can rig an executable that can be modified
and still have the same md5.

>With the above results, it would be possible to officially distribute
>nice behaving software but present specific targets with modified
>packages that do evil.

Yup. Or the security team could just plant a regular backdoor, and not
worry about the md5 hash. A sha hash isn't going to change that at all.
If you don't trust the security team, you probably shouldn't install
security updates.

Mike Stone


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Dale Amon
In reply to this post by Joey Hess
On Tue, Jun 12, 2007 at 07:39:38PM -0400, Joey Hess wrote:

> Bernd Eckenfels wrote:
> > Because open source is all about choice.
>
> So it's there because of a platitude?
>
> > There might be admins using dpkg -i
> > or security officers who build their local mirrors manually.
>
> Then why don't we include md5sums and wget commands for all packages in
> stable point release annoucements? Why not include them in major release
> announcements too? Or are these things somehow less "all about choice"?

Yes, there are a lot of us who use dpkg -i, and do it
very often. I may be missing something in this thread
because it seems to blatently obvious to me that this
is a necessary and important tool that I am having
difficulty understanding where this is going.




--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Steffen Schulz
In reply to this post by Michael Stone-2
On 070614 at 00:00, Michael Stone wrote:
> On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote:
> >http://www.cits.rub.de/MD5Collisions/
> >One example how to create two files with same hash that act
> >differently. Should work with most active content.
> Cool. So the security team can rig an executable that can be modified
> and still have the same md5.

Point was: md5 collisions are a real-world problem.

> >With the above results, it would be possible to officially distribute
> >nice behaving software but present specific targets with modified
> >packages that do evil.
> Yup. Or the security team could just plant a regular backdoor, [..]

The critical bit was included in the sentence you removed:
What hashes does apt-secure use?

Judging from this documentation, md5 is used for apt-secure, too:
http://people.debian.org/~walters/monk.debian.net/apt-secure/x35.html

So every maintainer could distribute nice binaries and then inject
malicious packets to certain targets.


The overall point of writing my comment:

Don't check all conditions, protocols, use cases.
Just replace md5 some time soon.

> If you don't trust the security team, you probably shouldn't install
> security updates.

Sorry for being unclear,

Steffen
--
Um sich in einer Schafherde wohlzufühlen, muss man vor allem Schaf sein.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Michael Stone-2
On Thu, Jun 14, 2007 at 11:37:33AM +0200, Steffen Schulz wrote:
>On 070614 at 00:00, Michael Stone wrote:
>> On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote:
>> >http://www.cits.rub.de/MD5Collisions/
>> >One example how to create two files with same hash that act
>> >differently. Should work with most active content.
>> Cool. So the security team can rig an executable that can be modified
>> and still have the same md5.
>
>Point was: md5 collisions are a real-world problem.

If they are, you've failed to show it.

>> >With the above results, it would be possible to officially distribute
>> >nice behaving software but present specific targets with modified
>> >packages that do evil.
>> Yup. Or the security team could just plant a regular backdoor, [..]
>
>The critical bit was included in the sentence you removed:
>What hashes does apt-secure use?
>
>Judging from this documentation, md5 is used for apt-secure, too:
>http://people.debian.org/~walters/monk.debian.net/apt-secure/x35.html
>
>So every maintainer could distribute nice binaries and then inject
>malicious packets to certain targets.

Every maintainer can do that without dicking around with md5 collisions.

>> If you don't trust the security team, you probably shouldn't install
>> security updates.
>
>Sorry for being unclear,

If you don't trust the debian maintainers, you probably shouldn't
install debian. Sorry for being unclear.

Mike Stone


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Steffen Schulz-2
On 070614 at 13:40, Michael Stone wrote:
> >So every maintainer could distribute nice binaries and then inject
> >malicious packets to certain targets.
> Every maintainer can do that without dicking around with md5 collisions.

Not as good. The chances of detection grow with the install base.


> If you don't trust the debian maintainers, you probably shouldn't
> install debian.

Trust is something that is to be reduced where possible.

If for whatever reason people get untrustworthy, it would be nice to
know as soon as possible, no? Government, Money, ..


And again, this is just one attack vector. To check the impact and list
the mitigating factors sure is good for employment. Security design is
something else.

I don't say it's highly critical. But usage of md5 and sha-1 should be
discouraged. The attacks will only get better. Systems should migrate,
however slow they think is appropriate.


/Steffen


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Goswin von Brederlow
In reply to this post by Bernd Eckenfels
Bernd Eckenfels <[hidden email]> writes:

> In article <[hidden email]> you wrote:
>> I don't understand why DSAs for etch include md5sums and manual upgrade
>> instructions at all. Apt can verify the checksum and gpg signature and
>> handle the upgrade after all, and probably more securely than the
>> average user following the manual instructions.
>
> Because open source is all about choice. There might be admins using dpkg -i
> or security officers who build their local mirrors manually.

Then they can wget the Release.gpg file, Release file, Packages file
and check each in turn. Their choice.

As for local mirrors: debmirror and reprepro already check the
Release.gpg file if wanted and anybody using something else to mirror
should do so too.

So both aren't really good arguments to complicate the mails.

> Gruss
> Bernd

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to replace MD5?

Florian Weimer
In reply to this post by Steffen Schulz
* Steffen Schulz:

> On 070613 at 10:43, Florian Weimer wrote:
>> > AND the fact that it needs to be a valid .deb archive, they are
>> > probably more than strong enough.
>
> This is actually not much of a problem:
>
> http://www.cits.rub.de/MD5Collisions/
>
> One example how to create two files with same hash that act
> differently. Should work with most active content.

The problem is ambiguous content, not the collision.  This has been
thoroughly debunked, I don't know why they continue publishing this.

It's easy to exploit their fictional document signing process without
creating an MD5 collision, which strongly suggests ("proves") that the
process itself is flawed.

Since you are located at RUB, could you please make sure that they
correct their analysis?

> Kaminsky did the same with self-extracting executables:
>
> http://www.doxpara.com/md5_someday.pdf

Yeah, but the evil twins must be created *by* *the* *same* *party*.
In the Debian case, this party is already trusted, so the current
attacks make no difference.

>> That, and the "evil twin" package would have to be prepared by the
>> securty team as well, which isn't a relevant scenario (because they
>> could put a backdoor in the original without attacking the hash).

> So apt-get signatures use a secure hash function?

Secure against currently known attacks, yes.  And we can distribute a
new hash function to clients pretty easily (something which is quite
unusual).

> With the above results, it would be possible to officially distribute
> nice behaving software but present specific targets with modified
> packages that do evil.

Yeah, right.  Guess what?  Distributors can do this even without using
MD5 attacks.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12