Question related to the Hash-Algorithms used for the Ports

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

Question related to the Hash-Algorithms used for the Ports

Sebastian Rother
During a report of the german news-website "Heise.de" experts
(Christian Rechberger and Christophe De Cannihre) on the Crypto2006 (a
conference) talked about at least one practical attack aggainst SHA-1.

The demonstration was made with a limited Version of SHA-1 but
cryptographic scientist said the attack would also be practical again
the normal version wich is widly in use.

Rechberger and De Cannihre said that they exspect a even more practical
attack against the normal SHA1 after some optimisations of their method.

The Ports-System uses MD5 and SHA1 wich are both now, at least for
cryptographic experts, brocken and not realy trustfull anymore. So 2 of
3 Algorithms used by the Ports-System are in fact weak.
Wouldn`t it be about time to think about alternatives?
Experts said that SHA 512 may rise the border for an sucessfull attack.

I would like to request the replacement of SHA-1 with SHA512 and to
kick out MD5 out of the Ports-System.
Using RipeMD with more bits would be usefull too (Ripe-MD is not
limited to 160Bits).

MD5 could get replaced with Whirpool wich is recommended by the
NESSIE-Project and wich is also a ISO-Standard.
Alternatives could be Tiger2 or HAVAL wich are also considred secure.

I think one of the Problems is that OpenSSL provides just a wide range
of unsecure HASH-Functons like MD2/4/5 SHA and now also SHA1.
The only algorithm considred as secure is the Ripe-MD (or rmd)
algorithm.

So no matter what you`ll do (as developers of OpenBSD) the question
came up one more time and I think some peoples should start looking for
alternative HASH-Algorithms used in the Ports.


Links for Nessie:
http://www.cryptonessie.org/

Kind regards,
Sebastian Rother

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Seth Hanford
> So no matter what you`ll do (as developers of OpenBSD) the question
> came up one more time and I think some peoples should start looking for
> alternative HASH-Algorithms used in the Ports.

The distinfo files contain size as well as MD5, SHA1 and RMD160 hashes.
From my tests (with make fetch, make checksum and make package) Size and
SHA1 are checked. I would imagine that you would be hard pressed (I hate
to say impossible, but it seems HIGHLY unlikely) to find a hashing
weakness that could be exploited such that all 3 hashes and the file
size were identical to a "known good" distinfo.

Instead of spending time finding and implementing new hashes, the
infrastructure need only check all the hashes instead of just SHA1 (or
two of the three, even) & size. Looking through ports(7) and
bsd.port.mk(5), I didn't find such an option, but it may already exist.

- Seth

> Links for Nessie:
> http://www.cryptonessie.org/
>
> Kind regards,
> Sebastian Rother

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Kjell-5
In reply to this post by Sebastian Rother
> During a report of the german news-website "Heise.de" experts
> (Christian Rechberger and Christophe De Cannihre) on the Crypto2006 (a
> conference) talked about at least one practical attack aggainst SHA-1.

What type of attack? A

>
> The demonstration was made with a limited Version of SHA-1 but
> cryptographic scientist said the attack would also be practical again
> the normal version wich is widly in use.
>
> Rechberger and De Cannihre said that they exspect a even more practical
> attack against the normal SHA1 after some optimisations of their method.
>
> The Ports-System uses MD5 and SHA1 wich are both now, at least for
> cryptographic experts, brocken and not realy trustfull anymore. So 2 of
> 3 Algorithms used by the Ports-System are in fact weak.
> Wouldn`t it be about time to think about alternatives?
> Experts said that SHA 512 may rise the border for an sucessfull attack.
>
> I would like to request the replacement of SHA-1 with SHA512 and to
> kick out MD5 out of the Ports-System.
> Using RipeMD with more bits would be usefull too (Ripe-MD is not
> limited to 160Bits).
>
> MD5 could get replaced with Whirpool wich is recommended by the
> NESSIE-Project and wich is also a ISO-Standard.
> Alternatives could be Tiger2 or HAVAL wich are also considred secure.
>
> I think one of the Problems is that OpenSSL provides just a wide range
> of unsecure HASH-Functons like MD2/4/5 SHA and now also SHA1.
> The only algorithm considred as secure is the Ripe-MD (or rmd)
> algorithm.
>
> So no matter what you`ll do (as developers of OpenBSD) the question
> came up one more time and I think some peoples should start looking for
> alternative HASH-Algorithms used in the Ports.
>
>
> Links for Nessie:
> http://www.cryptonessie.org/
>
> Kind regards,
> Sebastian Rother

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Kjell-5
In reply to this post by Sebastian Rother
> During a report of the german news-website "Heise.de" experts
> (Christian Rechberger and Christophe De Cannihre) on the Crypto2006 (a
> conference) talked about at least one practical attack aggainst SHA-1.

Are you referring to a collision attack,  or a second preimage attack?

i.e. can an attacker produce two files with the same SHA-1 hash,
or can they construct a file that matches a given SHA-1?

There's a huge difference, especially in the case of the ports tree.

> The Ports-System uses MD5 and SHA1 wich are both now, at least for
> cryptographic experts, brocken and not realy trustfull anymore. So 2 of
> 3 Algorithms used by the Ports-System are in fact weak.

Again, there's a distinction between the two attacks. A very important one,
since a collision attack doesn't really help a would-be ports-tree attacker.

> I think one of the Problems is that OpenSSL provides just a wide range
> of unsecure HASH-Functons like MD2/4/5 SHA and now also SHA1.
> The only algorithm considred as secure is the Ripe-MD (or rmd)
> algorithm.

says who?

> So no matter what you`ll do (as developers of OpenBSD) the question
> came up one more time and I think some peoples should start looking for
> alternative HASH-Algorithms used in the Ports.

And I think people should start looking for secure hash algorithms,
period, but that's going to take a while. A LONG while.

-kj

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Joachim Schipper
In reply to this post by Sebastian Rother
On Thu, Aug 24, 2006 at 07:57:07PM +0200, Sebastian Rother wrote:

> During a report of the german news-website "Heise.de" experts
> (Christian Rechberger and Christophe De Cannihre) on the Crypto2006 (a
> conference) talked about at least one practical attack aggainst SHA-1.
>
> The demonstration was made with a limited Version of SHA-1 but
> cryptographic scientist said the attack would also be practical again
> the normal version wich is widly in use.
>
> Rechberger and De Cannihre said that they exspect a even more practical
> attack against the normal SHA1 after some optimisations of their method.
>
> The Ports-System uses MD5 and SHA1 wich are both now, at least for
> cryptographic experts, brocken and not realy trustfull anymore.

Mmm... you didn't search the archives, did you?

> So 2 of
> 3 Algorithms used by the Ports-System are in fact weak.
> Wouldn`t it be about time to think about alternatives?
> Experts said that SHA 512 may rise the border for an sucessfull attack.
>
> I would like to request the replacement of SHA-1 with SHA512 and to
> kick out MD5 out of the Ports-System.
> Using RipeMD with more bits would be usefull too (Ripe-MD is not
> limited to 160Bits).
>
> MD5 could get replaced with Whirpool wich is recommended by the
> NESSIE-Project and wich is also a ISO-Standard.
> Alternatives could be Tiger2 or HAVAL wich are also considred secure.
>
> I think one of the Problems is that OpenSSL provides just a wide range
> of unsecure HASH-Functons like MD2/4/5 SHA and now also SHA1.
> The only algorithm considred as secure is the Ripe-MD (or rmd)
> algorithm.
>
> So no matter what you`ll do (as developers of OpenBSD) the question
> came up one more time and I think some peoples should start looking for
> alternative HASH-Algorithms used in the Ports.

The current spade of attacks against MD5 and SHA1 are interesting and
cause for concern; however, they are birthday attacks - the attacker can
produce two (to a certain extent, arbitrarily chosen by the attacker)
plaintexts which produce the same hash.

However, in the ports system, an attacker would have to create a
collision with a known plaintext (in other words, find a file that has
the same hash as a known file). This is an entirely different, and much
more difficult attack. And that completely ignores the fact that what
you discover must be at least a proper gzip file, containing a proper
tar archive, and probably should contain a mostly-functional version of
the program.

This is not currently feasible, and if it ever does become a problem,
verifying all three signatures (SHA1, RIPEMD160, MD5) would very likely
make the attack completely infeasible with only a minor change to the
system. (According to my reading of bsd.port.mk(5), only SHA1 is
currently checked [by default, see the man page for the gory details as
always]; as seen above, this makes sense.)

However, using MD5 or SHA1 for a GnuPG signature is not necessarily a
good idea; many people have switched to RIPEMD160, which does not seem
to be vulnerable at this time and has very good interoperability with
other PGP-ish programs.

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Sebastian Rother
In reply to this post by Kjell-5
On Thu, 24 Aug 2006 12:53:35 -0600
[hidden email] wrote:

> > During a report of the german news-website "Heise.de" experts
> > (Christian Rechberger and Christophe De Cannihre) on the Crypto2006 (a
> > conference) talked about at least one practical attack aggainst SHA-1.
>
> Are you referring to a collision attack,  or a second preimage attack?
>
> i.e. can an attacker produce two files with the same SHA-1 hash,
> or can they construct a file that matches a given SHA-1?
>
> There's a huge difference, especially in the case of the ports tree.

Well my references are those websites/files (I also think they explain
it much better then I could do it):

First notice:
http://www.heise-security.co.uk/news/77244

Fund a report wich seams to confirm that there`s a problem:
http://www.ni.din.de/sixcms/media.php/1377/SC27N5147_statement_on_
SHA-1_May2006.pdf?backend_call=true#search=%22crypto2006%20SHA1%22

But I wans`t able to find PDFs written by the sicentists.
So if anybody finds those PDF (well "Crypto2006 Website" seams not to
contain them) pls let me know.


Kind regards,
Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Martin Schröder
In reply to this post by Joachim Schipper
2006/8/24, Joachim Schipper <[hidden email]>:

> The current spade of attacks against MD5 and SHA1 are interesting and
> cause for concern; however, they are birthday attacks - the attacker can
> produce two (to a certain extent, arbitrarily chosen by the attacker)
> plaintexts which produce the same hash.
>
> However, in the ports system, an attacker would have to create a
> collision with a known plaintext (in other words, find a file that has
> the same hash as a known file). This is an entirely different, and much
> more difficult attack. And that completely ignores the fact that what
> you discover must be at least a proper gzip file, containing a proper
> tar archive, and probably should contain a mostly-functional version of
> the program.

This seems to be possible to a certain extend.

The heise article is here:
http://www.heise.de/newsticker/meldung/77235
babelfish: http://tinyurl.com/ojss8

Here are some references:
http://www.iaik.tugraz.at/aboutus/people/rechberger/index.php

Best
   Martin

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Dries Schellekens
In reply to this post by Sebastian Rother
Sebastian Rother wrote:

> During a report of the german news-website "Heise.de" experts
> (Christian Rechberger and Christophe De Cannihre) on the Crypto2006 (a
> conference) talked about at least one practical attack aggainst SHA-1.

It is De Cannihre. I should know because was a collegue of me for more
than 3 year ;)

The results of their attack will only be presented today during the NIST
Second Cryptographic Hash Workshop
http://www.csrc.nist.gov/pki/HashWorkshop/program.htm

> The demonstration was made with a limited Version of SHA-1 but
> cryptographic scientist said the attack would also be practical again
> the normal version wich is widly in use.
 >
 > Rechberger and De Cannihre said that they exspect a even more
 > practical attack against the normal SHA1 after some optimisations of
 > their method.

The limited version is 64 rounds out of 80. Breaking the full version
will definately require bigger time complexity. Say a few year with a
few 1000 computers. That is more than the release cycle of OpenBSD ;)

And the attack only allows 25% of the message to be freely selected, the
other 75% is determined by attack. In the case of ports the message is
compressed (tar.gz), so rather random. It is highly unlikely you can
find a collision of 2 almost random compressed packages. The attack
could be a bit more practical if the messages are ASCI text (on heise.de
they suggest html documents), but this is not the case.

BTW this is documented on http://www.cryptography.com/cnews/hash.html
"Q: Do these attacks allow somebody to break tools that use MD5 or SHA-1
to check for malicious binaries?
A: Not usually, as this would require a preimage attack. It would,
however, be possible for someone to construct an innocuous program and a
malicious program with the same hash. If this adversary could get the
innocuous version on the "good" list (e.g. by having a trusted authority
sign the hash value), the malicious program would also be accepted."

> The Ports-System uses MD5 and SHA1 wich are both now, at least for
> cryptographic experts, brocken and not realy trustfull anymore. So 2 of
> 3 Algorithms used by the Ports-System are in fact weak.

Finding a collision for both MD5 and SHA-1 at the same time is
completely improbable.

> Wouldn`t it be about time to think about alternatives?
> Experts said that SHA 512 may rise the border for an sucessfull attack.
 >
> I would like to request the replacement of SHA-1 with SHA512 and to
> kick out MD5 out of the Ports-System.
> Using RipeMD with more bits would be usefull too (Ripe-MD is not
> limited to 160Bits).

RIPEMD-128 is not so safe either, while RIPEMD-160 should be fine for
the time being. See http://www.infosec.sdu.edu.cn/paper/md4-ripemd-attck.pdf

> MD5 could get replaced with Whirpool wich is recommended by the
> NESSIE-Project and wich is also a ISO-Standard.
> Alternatives could be Tiger2 or HAVAL wich are also considred secure.

HAVAL is not so safe either. See http://eprint.iacr.org/2004/199.pdf

Tiger2 is a rather new version of Tiger, so it has not be analysed
thoroughly. However, the performance of Tiger sucks on non-64 bit
processors, because it has been designed for 64 bit...

> I think one of the Problems is that OpenSSL provides just a wide range
> of unsecure HASH-Functons like MD2/4/5 SHA and now also SHA1.
> The only algorithm considred as secure is the Ripe-MD (or rmd)
> algorithm.

OpenSSL contains a lot of other depreciated cryptographic algorithms,
like RC2, RC4, DES. Don't use what is not secure.

> So no matter what you`ll do (as developers of OpenBSD) the question
> came up one more time and I think some peoples should start looking for
> alternative HASH-Algorithms used in the Ports.
>
>
> Links for Nessie:
> http://www.cryptonessie.org/

The NESSIE project stopped more than 3 years ago and this was before the
Wang et al. attacks were published. So the results are no longer up to
date. It is better to use the suggestions from the ECRYPT project. See
http://www.ecrypt.eu.org/documents/STVL-ERICS-2-HASH_STMT-1.1.pdf


Cheers,

Dries

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Dries Schellekens
Dries Schellekens wrote:
> Sebastian Rother wrote:
>
>> During a report of the german news-website "Heise.de" experts
>> (Christian Rechberger and Christophe De Cannihre) on the Crypto2006 (a
>> conference) talked about at least one practical attack aggainst SHA-1.
>
> It is De Cannihre. I should know because was a collegue of me for more
> than 3 year ;)

Damn, this got corrupted for me as well. It should be De Canniere ;)

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Joerg Sonnenberger
In reply to this post by Seth Hanford
On Thu, Aug 24, 2006 at 02:43:30PM -0400, Seth Hanford wrote:
> Instead of spending time finding and implementing new hashes, the
> infrastructure need only check all the hashes instead of just SHA1 (or
> two of the three, even) & size. Looking through ports(7) and
> bsd.port.mk(5), I didn't find such an option, but it may already exist.

It does check all three.

Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Seth Hanford
Joerg Sonnenberger wrote:
> On Thu, Aug 24, 2006 at 02:43:30PM -0400, Seth Hanford wrote:
>> Instead of spending time finding and implementing new hashes, the
>> infrastructure need only check all the hashes instead of just SHA1 (or
>> two of the three, even) & size. Looking through ports(7) and
>> bsd.port.mk(5), I didn't find such an option, but it may already exist.
>
> It does check all three.

Can you enlighten me how? My tests showed otherwise:

OpenBSD 3.9-stable (GENERIC.MP) #0: Fri Jun 16 10:46:24 EDT 2006
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC.MP

$cd /usr/ports/devel/p5-Cache-Mmap
$cat distinfo
MD5 (Cache-Mmap-0.09.tar.gz) = fef44673771a0f1f14982ae719f57221
RMD160 (Cache-Mmap-0.09.tar.gz) = bea768cfe8e6cb1207680bf676c4e3d097737dd3
SHA1 (Cache-Mmap-0.09.tar.gz) = c2088ec6c3bba6eafe09ba71fa0508a4699e51cf
SIZE (Cache-Mmap-0.09.tar.gz) = 21463

$sudo make fetch
===>  Checking files for p5-Cache-Mmap-0.09
>> Cache-Mmap-0.09.tar.gz doesn't seem to exist on this system.
>> Fetch
ftp://ftp.funet.fi/pub/languages/perl/CPAN/modules/by-module/Cache/Cache-Mmap-0.09.tar.gz.
Unknown command
100% |**************************************************| 21463
00:00
>> Size matches for /usr/ports/distfiles/Cache-Mmap-0.09.tar.gz
   ^^^^^^^^^^^^
$vi distinfo

$cat distinfo
MD5 (Cache-Mmap-0.09.tar.gz) = fef44673771a0f1f14982ae719f57220
                                                            ^^^
RMD160 (Cache-Mmap-0.09.tar.gz) = bea768cfe8e6cb1207680bf676c4e3d097737dd2
                                     ^^^
SHA1 (Cache-Mmap-0.09.tar.gz) = c2088ec6c3bba6eafe09ba71fa0508a4699e51cf
SIZE (Cache-Mmap-0.09.tar.gz) = 21463

$sudo make package
===>  Checking files for p5-Cache-Mmap-0.09
`/usr/ports/distfiles/Cache-Mmap-0.09.tar.gz' is up to date.
>> Checksum OK for Cache-Mmap-0.09.tar.gz. (sha1)
                                           ^^^^^^
===>  Extracting for p5-Cache-Mmap-0.09
===>  Patching for p5-Cache-Mmap-0.09
===>  Configuring for p5-Cache-Mmap-0.09
WARNING! I can't test for the existence of mmap() yet.
         If your system does not provide mmap(), you will be unable
         to compile this module.
Checking if your kit is complete...
Looks good
Writing Makefile for Cache::Mmap
===>  Building for p5-Cache-Mmap-0.09

<SNIP>

===>  Faking installation for p5-Cache-Mmap-0.09

<SNIP>

===>  Building package for p5-Cache-Mmap-0.09
Switching to /usr/ports/devel/p5-Cache-Mmap/pkg/PFRAG.shared
Link to /usr/ports/packages/i386/ftp/p5-Cache-Mmap-0.09.tgz
Link to /usr/ports/packages/i386/cdrom/p5-Cache-Mmap-0.09.tgz

Is this something I can enable (and put into site.tgz?) to secure my
builds? Nothing so far in my cursory checks/searches (aka for
"checksum") in man bsd.port.mk or man ports. Can it be default? I'm fine
if it's only an "enable-me" feature (for example if checksumming on some
platforms is slow/undesirable) - so long as I can willfully incur the
performance/other hit for safety.

- Seth

> Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Matthias Bauer-3
In reply to this post by Joerg Sonnenberger
On Fri, Aug 25, 2006 at 02:50:44PM +0200, Joerg Sonnenberger wrote:
> On Thu, Aug 24, 2006 at 02:43:30PM -0400, Seth Hanford wrote:
> > Instead of spending time finding and implementing new hashes, the
> > infrastructure need only check all the hashes instead of just SHA1 (or
> > two of the three, even) & size. Looking through ports(7) and
> > bsd.port.mk(5), I didn't find such an option, but it may already exist.
>
> It does check all three.

No, it checks the first matching in distinfo. The following quick patch
changes that.

Best regards,

Matthias

Index: bsd.port.mk
===================================================================
RCS file: /home/bauerm/cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.763
diff -u -r1.763 bsd.port.mk
--- bsd.port.mk 7 Aug 2006 08:57:18 -0000 1.763
+++ bsd.port.mk 25 Aug 2006 13:52:31 -0000
@@ -1602,27 +1602,27 @@
   cd ${DISTDIR}; OK=true; list=''; \
  for file in ${_CKSUMFILES}; do \
   for cipher in ${PREFERRED_CIPHERS}; do \
- set -- `grep -i "^$$cipher ($$file)" $$checksum_file` && break || \
-  ${ECHO_MSG} ">> No $$cipher checksum recorded for $$file."; \
-  done; \
-  case "$$4" in \
- "") \
-  ${ECHO_MSG} ">> No checksum recorded for $$file."; \
-  OK=false;; \
- "IGNORE") \
-  echo ">> Error: checksum for $$file is set to IGNORE in distinfo"; \
-  OK=false;; \
- *) \
-  CKSUM=`$$cipher < $$file`; \
-  case "$$CKSUM" in \
-   "$$4") \
-  ${ECHO_MSG} ">> Checksum OK for $$file. ($$cipher)";; \
- *) \
-  echo ">> Checksum mismatch for $$file. ($$cipher)"; \
-  list="$$list $$file $$cipher $$4"; \
+ set -- `grep -i "^$$cipher ($$file)" $$checksum_file` || \
+  ${ECHO_MSG} ">> No $$cipher checksum recorded for $$file." || continue; \
+ case "$$4" in \
+ "") \
+  ${ECHO_MSG} ">> No checksum recorded for $$file."; \
+  OK=false;; \
+ "IGNORE") \
+  echo ">> Error: checksum for $$file is set to IGNORE in distinfo"; \
   OK=false;; \
-  esac;; \
-  esac; \
+ *) \
+  CKSUM=`$$cipher < $$file`; \
+  case "$$CKSUM" in \
+   "$$4") \
+  ${ECHO_MSG} ">> Checksum OK for $$file. ($$cipher)";; \
+ *) \
+  echo ">> Checksum mismatch for $$file. ($$cipher)"; \
+  list="$$list $$file $$cipher $$4"; \
+  OK=false;; \
+  esac;; \
+  esac; \
+ done; \
  done; \
  set --; \
  if ! $$OK; then \

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Joerg Sonnenberger
On Fri, Aug 25, 2006 at 03:56:19PM +0200, Matthias Bauer wrote:

> On Fri, Aug 25, 2006 at 02:50:44PM +0200, Joerg Sonnenberger wrote:
> > On Thu, Aug 24, 2006 at 02:43:30PM -0400, Seth Hanford wrote:
> > > Instead of spending time finding and implementing new hashes, the
> > > infrastructure need only check all the hashes instead of just SHA1 (or
> > > two of the three, even) & size. Looking through ports(7) and
> > > bsd.port.mk(5), I didn't find such an option, but it may already exist.
> >
> > It does check all three.
>
> No, it checks the first matching in distinfo. The following quick patch
> changes that.

Yeah, I was looking at the wrong packaging system when I wrote that,
since I confused the mailing list :-)

Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Thorsten Glaser-3
Joerg Sonnenberger dixit:

>> > It does check all three.
>>
>> No, it checks the first matching in distinfo. The following quick patch
>> changes that.
>
>Yeah, I was looking at the wrong packaging system when I wrote that,
>since I confused the mailing list :-)

You look at MirPorts? ;)

//mirabile
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence. -- Coywolf Qi Hunt

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Marc Bevand
In reply to this post by Dries Schellekens
Dries Schellekens 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.

--
 Marc Bevand                              http://epita.fr/~bevand_m
 Computer Science School EPITA - System, Network and Security Dept.

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Dries Schellekens
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/STVL-ERICS-2-HASH_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.


Cheers,

Dries

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Thorsten Glaser-3
In reply to this post by Marc Bevand
Marc Bevand dixit:

>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.

No, I'd rather concatenate RIPEMD-160 (from the same family as
SHA and MD5)9 with some unrelated algorithm (e.g. CRC, until
Tiger(2) or Whirlpool are in cksum(1) and libc integrated).

9) The only one from that family to be unbroken yet - ok,
   RIPEMD-128 (not the 128 bit hash RIPEMD) isn't either,
   but it's a little short.

//mirabile
--
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
                                         -- Henry Nelson, March 1999

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Marc Bevand
Thorsten Glaser wrote:
| Marc Bevand dixit:
|
| >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.
|
| No, I'd rather concatenate RIPEMD-160 [...]

Hum, I was not serious. This was a rhetorical suggestion.

--
 Marc Bevand                              http://epita.fr/~bevand_m
 Computer Science School EPITA - System, Network and Security Dept.

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Marc Bevand
In reply to this post by Dries Schellekens
Dries Schellekens wrote:
|
| All this is irrelevant for the application we are looking at, namely
| OpenBSD ports.

Sorry if I did not make myself clear. I totally agree that all the
recent collision attacks against MD5 and SHA-1 are irrelevant to the
OpenBSD ports. I just wanted to state the fact that a collision attack
on both MD5 and SHA-1 is not something that can be considered
improbable.

--
 Marc Bevand                              http://epita.fr/~bevand_m
 Computer Science School EPITA - System, Network and Security Dept.

Reply | Threaded
Open this post in threaded view
|

Re: Question related to the Hash-Algorithms used for the Ports

Marc Espie-2
In reply to this post by Dries Schellekens
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/STVL-ERICS-2-HASH_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).