GNU bug report logs - #13949
24.3.50; `fill-paragraph' should not always put the buffer as modified

Previous Next

Full log

View this message in rfc822 format

From: "Petros Travioli" <travioli <at> gmx.de>
To: "Andreas Schwab" <schwab <at> linux-m68k.org>, 13949 <at> debbugs.gnu.org
Subject: bug#13949: Aw: Re: bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy
Date: Mon, 28 Mar 2016 15:29:19 +0200

> > But that's exactly what happens when you are using hash functions to
> > verify buffer equality, just with a more complicated mathematical
> > formulation and at a slightly different scale.
> >
> > So don't use hash functions to a two-sided correct answer to test buffer
> > equality. For a one-sided answer (if hash(x) != hash(y) then x != y), you
> > are fine.
> 
> There is a difference between a hash function and a cryptographic hash
> function.  An inportant property of a cryptographic hash function is the
> avalanche effect, that means a small change in the plaintext will result
> in a big change in the hash value.  That makes such a hash function
> suitable for the reverse condition x != y => hash(x) != hash(y), with a
> very high probability of being true.
> 
So far most old crypto functions have been broken. There is no doubt this will happen to any newer one sooner or later. If any single person would lose his work because of a random collision, this is an argument agains crypto hash functions.

I am citing RFC 6151 (https://tools.ietf.org/html/rfc6151):

"MD5 is no longer acceptable where collision resistance is required..."

If the developers (I think, it was Eli who embraced the patch) are so sure about collision freedom:

Eli, if you are so sure about MD5, please post your password MD5 hash here with login data and a consent that anyone is allowed to hack in. I do not want to go into prison. Then wait for, say, 1 week.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.