md5?

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

md5?

Marc Balmer-2
shouldn't we abandon md5 in favor of e.g. sha256?

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Brad Smith-14
On Thursday 05 February 2009 17:18:43 Marc Balmer wrote:
> shouldn't we abandon md5 in favor of e.g. sha256?

SHA256 has been the default for 2 years now.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Hannah Schroeter
Hi!

On Thu, Feb 05, 2009 at 05:31:06PM -0500, Brad wrote:
>On Thursday 05 February 2009 17:18:43 Marc Balmer wrote:
>> shouldn't we abandon md5 in favor of e.g. sha256?

>SHA256 has been the default for 2 years now.

For ports, yes.  For packages, more recently, IIRC.  For the "MD5" file
in the base distribution, not at all.

However, I don't see it as *so very* critical.  The practical attacks
against MD5 are birthday attacks, not preimages for a given hash.
At least not yet.

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Christian Weisgerber
Hannah Schroeter <[hidden email]> wrote:

> However, I don't see it as *so very* critical.  The practical attacks
> against MD5 are birthday attacks, not preimages for a given hash.
> At least not yet.

Actually, if you can overwrite or append a chunk of data, you can
create an MD5 collision at will.  This allows for some practical
attacks.

In particular, arbitrary data can be appended to a gzipped file;
gzip will just ignore it on extraction.

In combination this means that creating a modified gzipped file
that shares the MD5 hash and the size of the original is quite
achievable.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Marc Espie-2
In reply to this post by Hannah Schroeter
On Thu, Feb 12, 2009 at 04:05:14PM +0100, Hannah Schroeter wrote:

> Hi!
>
> On Thu, Feb 05, 2009 at 05:31:06PM -0500, Brad wrote:
> >On Thursday 05 February 2009 17:18:43 Marc Balmer wrote:
> >> shouldn't we abandon md5 in favor of e.g. sha256?
>
> >SHA256 has been the default for 2 years now.
>
> For ports, yes.  For packages, more recently, IIRC.  For the "MD5" file
> in the base distribution, not at all.

Packages were dependent on two things:
- sha256 support in perl, either through home-made ssl interface (Simon
was working on that), or through the base distro (which is what happened
with perl 5.10).
- full PLIST checks, in particular wrt weird modes. These days, packages
will complain if you have setuid files in them that do not have corresponding
annotations in the packing-list.

The cool thing about it is the object-oriented design of the tools. With the
proper abstraction, suddenly packages would cope with md5 or sha256 without
errors, and it was just a question of switching the default to sha256.

I make some big efforts in ensuring backward compatibility for package tools.
I haven't tried recently, but it used to be the case that you could go back
to a 3.6 installed machine, and the package tools would still grok the
installed packages and update them more or less correctly.

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Hannah Schroeter
Hi, Marc!

On Thu, Feb 12, 2009 at 05:44:17PM +0100, Marc Espie wrote:
>On Thu, Feb 12, 2009 at 04:05:14PM +0100, Hannah Schroeter wrote:
>> On Thu, Feb 05, 2009 at 05:31:06PM -0500, Brad wrote:
>> >On Thursday 05 February 2009 17:18:43 Marc Balmer wrote:
>> >> shouldn't we abandon md5 in favor of e.g. sha256?

>> >SHA256 has been the default for 2 years now.

>> For ports, yes.  For packages, more recently, IIRC.  For the "MD5" file
>> in the base distribution, not at all.

>Packages were dependent on two things:
>[...]

Just to be sure, there was no intent to criticise the timing, especially
not with respect to packages, just to make sure there's no
misunderstanding about the extent of the SHA256 support that's already
been in for a longer time (checking distfiles in the ports tree).

And thanks for the detailed explanations, including those about the
aim to ensure backward interoperability even in the hope to make "big"
upgrades work even though officially only upgrades from one release to
the next one are supported, IIRC.

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Hannah Schroeter
In reply to this post by Christian Weisgerber
Hi!

On Thu, Feb 12, 2009 at 03:59:20PM +0000, Christian Weisgerber wrote:
>Hannah Schroeter <[hidden email]> wrote:

>> However, I don't see it as *so very* critical.  The practical attacks
>> against MD5 are birthday attacks, not preimages for a given hash.
>> At least not yet.

>Actually, if you can overwrite or append a chunk of data, you can
>create an MD5 collision at will.  This allows for some practical
>attacks.

>In particular, arbitrary data can be appended to a gzipped file;
>gzip will just ignore it on extraction.

>In combination this means that creating a modified gzipped file
>that shares the MD5 hash and the size of the original is quite
>achievable.

Ok, I was unaware that you can also, practically feasably, create
collisions for *given* hash values (which would be an attack against the
MD5 files of OpenBSD, for example, when someone checks the MD5 files
from many sources, but downloads the tarballs only from one).

What I am aware of is the birthday attacks (choosing some bits of *one*
chunk of data someone signs, in parallel crafting another chunk of data
with the same MD5 sum you can later substitute, e.g. the recent attack
against an SSL CA that still used MD5 for signing certificates).

So your scenario is creating a somewhat shorter malicious .tar.gz, and
kind of "compensating" for the hash value by varying the appended junk
(which is ignored by gzip) - are there already known feasible attacks
that do something like that?

Would it be too difficult to change the md5 invocation in the release
target in /usr/src/etc into sha1 or sha256 (i.e. cksum -a sha256), or
just to *add* them there? (And perhaps add creation of a kind of xMD5
file or xSHA... file into /usr/xenocara's Makefile, e.g. in the dist
target after maketars and checkflist... That would make checksums work
without needing to synchronize base vs. X builds on the build hosts.)

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Marc Espie-2
Well, there's no real need to philosophize about md5.

It's quite obvious it is broken as a secure hash.

There are some limited attacks, for now, but it's getting worse
and worse.  There are less and less constraints on what you can do,
and you really want to abandon that ship.

Remember the old saying:

attacks don't get worse, they only get better...


It's not quite obvious where this is going to go from there.

From what I know, sha1 is more or less in the same boat as md5. Only, it's a
bigger hash, so practical attacks don't work yet, but the mathematical
security of the hash is not any better than md5. People currently know how
to "brute-force" sha1 using only a small fraction of the possible space
(as far as I know, no practical attack yet, but not far off, and definitely
much easier than a truly secure hash of a similar size would allow).


I am not a professional cryptographer, but I've been told that sha256 is
more secure for now. Different algorithm (and much bigger space to explore,
in any case).


This should give us enough time until mathematicians understand secure hashes
a bit better, and give us some better algorithms. We're probably talking
two to five years...

I assume you're all aware there's an international bid for a secure hash,
along the same lines that led to the adoption of AES as a standard.

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Christian Weisgerber
In reply to this post by Hannah Schroeter
Hannah Schroeter <[hidden email]> wrote:

> Would it be too difficult to change the md5 invocation in the release
> target in /usr/src/etc into sha1 or sha256 (i.e. cksum -a sha256), or
> just to *add* them there?

Should be trivial, but that's not my decision.  And really, what's
the point?  Unless the MD5 file has a different distribution path,
it offers no security benefit.  It's handy to check for inadvertent
transfer corruption, that's all.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Alexander Hall
Christian Weisgerber wrote:

> Hannah Schroeter <[hidden email]> wrote:
>
>> Would it be too difficult to change the md5 invocation in the release
>> target in /usr/src/etc into sha1 or sha256 (i.e. cksum -a sha256), or
>> just to *add* them there?
>
> Should be trivial, but that's not my decision.  And really, what's
> the point?  Unless the MD5 file has a different distribution path,
> it offers no security benefit.  It's handy to check for inadvertent
> transfer corruption, that's all.

My upgrade script fetches the MD5 from ftp.openbsd.org as well as from
the local mirror of preference and bails out if they differ. At least
that would tell me if the mirror had been hacked.

...but then again, in case of a new snap on ftp.openbsd.org that has not
yet made it to the mirrors, combined widh an urge for updating (which I
almost always do from the local mirror), I tend to bypass that... :-P

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: md5?

Toni Mueller-7
In reply to this post by Christian Weisgerber

Hi,

On Thu, 12.02.2009 at 21:25:34 +0000, Christian Weisgerber <[hidden email]> wrote:
> Should be trivial, but that's not my decision.  And really, what's
> the point?  Unless the MD5 file has a different distribution path,
> it offers no security benefit.  It's handy to check for inadvertent
> transfer corruption, that's all.

yes, but this one could be easily fixed, imho (sort of, that is).

It would require someone signing a file with such hashes with -
preferably - a well connected OpenPGP key. Any one of the OpenBSD
developers should be able to create and/or use such a key of suitable
size (4096 bits, imho) with ease.

Only that some keys need to be published and widely advertized as being
used for that purpose. Please see eg. "debian-keyring" or
"debian-archive-keyring" for inspiration.


Kind regards,
--Toni++