Just got a pointer to this via ACM "TechNews Alert" for today: http://www.acm.org/technews/articles/2004-6/0818w.html#item2 Seems that "... French computer scientist Antoine Joux reported on Aug. 12 his discovery of a flaw in the MD5 algorithm, which is often used with digital signatures...." There's more in the article cited above. Peace, david -- David H. Wolfskill david@catwhisker.org Evidence of curmudgeonliness: becoming irritated with the usage of the word "speed" in contexts referring to quantification of network performance, as opposed to "bandwidth" or "latency."
Well while collisions are cryptographically significant, they don't necessarily impact any operational security of the the hash. (Since the collision merely means that there are possibly two inputs which will hash to the same digest). Where this could theoretically mean that someone could alter a signed message, we have to look at the chance that what was intended to be altered will satisfy the conditions for the collision. The only 'real' worry about this issue is that if MD5 is already cryptographically challenged in this manner, it may be more possible to find a way to reverse the hash. You can read the discussion here: http://www.rtfm.com/movabletype/archives/2004_08.html#001053 http://www.rtfm.com/movabletype/archives/2004_03.html#000820 On Wed, Aug 18, 2004 at 10:24:27AM -0700, David Wolfskill wrote:> Just got a pointer to this via ACM "TechNews Alert" for today: > > http://www.acm.org/technews/articles/2004-6/0818w.html#item2 > > Seems that "... French computer scientist Antoine Joux reported on > Aug. 12 his discovery of a flaw in the MD5 algorithm, which is often > used with digital signatures...." > > There's more in the article cited above. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Evidence of curmudgeonliness: becoming irritated with the usage of the > word "speed" in contexts referring to quantification of network > performance, as opposed to "bandwidth" or "latency." > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"-- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/
> Someone I was talking to made a point of highlighting that this is > what the Chinese Government is allowing to be published in this area > of research. That's enough to make you wonder what they've > discovered but not published...There is a fine line between false sense of security and conspiranoia, and when using *any* cryptographic system (which includes algorithms) you must decide where to put your trust. I think (this is a personal opinion) that such an important discovery is really hard to keep secret. Since cryptography became a public research area, it is quite likely for important discoveries to be widely known. Of course, researchers working for government agencies can keep their discoveries secret, but bear in mind that an apparently "harmless" Mathematics discovery can have a dramatic impact on cryptography. Although the example is obvious, imagine an article with a title such as: "A faster method to factorize integers constructed as the product of two primes given the constraints...". It could have a dramatic impact on the security of any system using the RSA algorithm. Do you think it is so easy to filter Mathematics research reports? This is the joy of basic research. In many cases (of course you know in my example!) you don't really know what the practical applications/consequences will be. Borja.
The reporter got mixed up. Antoine Joux published a SHA-0 collision, while the Chinese researchers, Xiaoyun Wang and co. put out the paper on collisions in MD5, MD4, HAVAL, and full RIPEMD. A copy can be found here: http://eprint.iacr.org/2004/199.pdf This is the second version, after they used the wrong IV's initially. They plan to release a more detailed version in the near future. I wouldn't just wave off the attack; they seem to be able to find collisions fairly quickly. For more info see recent posts on: http://www.mail-archive.com/cryptography%40metzdowd.com/ -- George F. Costanzo <afx@pkl.net> PGP Fingerprint: 1E4F 09F2 D637 B917 8D61 0413 4FBC 7DB0 1407 2B6D> -----Original Message----- > From: owner-freebsd-security@freebsd.org [mailto:owner-freebsd- > security@freebsd.org] On Behalf Of David Wolfskill > Sent: Thursday, August 19, 2004 3:24 AM > To: freebsd-security@freebsd.org > Subject: Report of collision-generation with MD5 > > Just got a pointer to this via ACM "TechNews Alert" for today: > > http://www.acm.org/technews/articles/2004-6/0818w.html#item2 > > Seems that "... French computer scientist Antoine Joux reported on > Aug. 12 his discovery of a flaw in the MD5 algorithm, which is often > used with digital signatures...." > > There's more in the article cited above. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Evidence of curmudgeonliness: becoming irritated with the usage of the > word "speed" in contexts referring to quantification of network > performance, as opposed to "bandwidth" or "latency."
> > On 18-Aug-2004 Mike Tancsa wrote: >> As I have no crypto background to evaluate some of the (potentially >> wild >> and erroneous) claims being made in the popular press* (eg >> http://news.com.com/2100-1002_3-5313655.html see quote below), one >> thing >> that comes to mind is the safety of ports. If someone can pad an >> archive >> to come up with the same MD5 hash, this would challenge the security >> of >> the FreeBSD ports system no ? > > I _believe_ answer is "no", because i _think_ the FreeBSD ports system > also > verify the size of the archive(s) (cat /usr/ports/any/any/distinfo to > see > what made me think that). > > Padding would modify archive size. Finding a backdoored version that > both > satisfy producing the same hash and being the same size is probably not > impossible, but how many years would it take ? > > > Now, i may be wrong. Any enlightement welcome. > > -- > Guy > _______________________________________________ >Why not adopt the OpenBSD method for ports. OpenBSD supplies 3 hash/digests for downloaded binaries and sources. Those OpenBSD guys leave nothing to chance. ports/databases/postgresql] scott% cat distinfo MD5 (postgresql-7.3.5.tar.gz) = ef2751173050b97fad8592ce23525ddf RMD160 (postgresql-7.3.5.tar.gz) = 83d5f713d7bfcf3ca57fb2bcc88d052982911d73 SHA1 (postgresql-7.3.5.tar.gz) = fbdab6ce38008a0e741f8b75e3b57633a36ff5ff Thanks, -- Scott A. Gerhardt, P.Geo. Gerhardt Information Technologies
On Wed, 25 Aug 2004, Scott Gerhardt wrote:> >> >> On 18-Aug-2004 Mike Tancsa wrote: >>> As I have no crypto background to evaluate some of the (potentially wild >>> and erroneous) claims being made in the popular press* (eg >>> http://news.com.com/2100-1002_3-5313655.html see quote below), one thing >>> that comes to mind is the safety of ports. If someone can pad an archive >>> to come up with the same MD5 hash, this would challenge the security of >>> the FreeBSD ports system no ? >> >> I _believe_ answer is "no", because i _think_ the FreeBSD ports system also >> verify the size of the archive(s) (cat /usr/ports/any/any/distinfo to see >> what made me think that). >> >> Padding would modify archive size. Finding a backdoored version that both >> satisfy producing the same hash and being the same size is probably not >> impossible, but how many years would it take ? >> >> >> Now, i may be wrong. Any enlightement welcome. >> >> -- >> Guy >> _______________________________________________ >> > > Why not adopt the OpenBSD method for ports. OpenBSD supplies 3 hash/digests > for downloaded binaries and sources. Those OpenBSD guys leave nothing to > chance. > > ports/databases/postgresql] scott% cat distinfo > MD5 (postgresql-7.3.5.tar.gz) = ef2751173050b97fad8592ce23525ddf > RMD160 (postgresql-7.3.5.tar.gz) = 83d5f713d7bfcf3ca57fb2bcc88d052982911d73 > SHA1 (postgresql-7.3.5.tar.gz) = fbdab6ce38008a0e741f8b75e3b57633a36ff5ffI would also opt for having (by default) additional hash algorithms. I would prefer using method of NetBSD: using an external program called digest ( see security/digest port) to select the algorithms. Oliver Eikemeier is working a ports building infrastructure and I think it would be a good idea to this new infrastructure would support multiple hash algorithm. The most easiest way would be to define a knob like PREFERED_HASH that would list the algorithms that system would prefer, and REQUIRED_HASH that would be required to checked: - makesum should generate all the PREFERED_HASH - fetch should fail if any of the REQUIRED_HASH failed additional bit to NetBSD digest should be extended to have SIZE "hash" - this is only for simplification of bsd.port.mk rules. Today setup would be: PREFERED_HASH= MD5 SIZE REQUIRED_HASH= MD5 SIZE (except when NO_SIZE defined) Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
Mohacsi Janos wrote:> [...] > I would also opt for having (by default) additional hash algorithms. I > would prefer using method of NetBSD: using an external program called > digest ( see security/digest port) to select the algorithms. Oliver > Eikemeier is working a ports building infrastructure and I think it > would be a good idea to this new infrastructure would support multiple > hash algorithm. The most easiest way would be to define a knob like > PREFERED_HASH that would list the algorithms that system would prefer, > and REQUIRED_HASH that would be required to checked: > - makesum should generate all the PREFERED_HASH > - fetch should fail if any of the REQUIRED_HASH faileddevel/portmk supports generation of multiple hashes, although it will just verify the first of the sufficient ones. the problem is to test this stuff before 5.3. -Oliver