[lug] Interesting sum "weakness"

[Tkil]

>>>>> "Jeffrey" == Jeffrey B Siegal <jbs at quiotix.com> writes:

Jeffrey> Good info, and it definitely makes sense to be cautious about
Jeffrey> MD5, but nothing here says that anyone can, at present "make
Jeffrey> it generate a specific output."

uh, that's what "create a collision" means.  a quote at length from
the message by hans dobbertin:

   1. [...] In this paper, as an example two versions of a contract
      are given with the same MD4 hash value. Alf sells his house to
      Ann, in the first version the price is $176,495 and in the
      second it is $276,495. The contracts have been prepared by
      Alf. Now if Ann signs the first version with $176,495 then Alf
      can altered to price to $276.495 ...  In principle this risk
      occurs, if you use a hash function for which (senseful)
      collisions can be found, whenever you allow another person to
      have influence on the contents of a document you are
      signing. Certainly this does not happen very often in practical
      applications. But sometimes you *must* have an agreement about a
      text (contract) which is then signed by two or more parties. And
      these are often just the most important applications!

this is discussing MD4, but he goes on to say:

   2. I suspect that the recent attack on MD5 compress can be refined
      and extended such that it might lead to MD5 collisions (matching
      the right IV) and perhaps then even to similar results as
      already obtained for MD4. Certainly this requires a lot of hard
      additional work.
   
   3. If you write a message for your own (nobody else has influence
      on it) and sign it using MD5 (and a strong public key algorithm,
      of course) then there is no danger that it can be altered (at
      least according to our knowledge today)!  Thus it is true that I
      guess almost all of you will have no risk using MD5, for
      instance in PGP.  However, if you accept 2., then in some cases
      there could be problems ...
   
   4. After all I have reservations against keeping MD5 as a (de
      facto) standard, because 2. might indicate that there is a
      serious security problem with MD5.

   5. My conclusions are: no reason for panic, but in future
      implementations better move away from MD5.

all taken from:

   http://www.uni-mainz.de/~pommeren/DSVorlesung/Material/MD5.Dobbertin

(in fact, i've quoted some 95% of that message.)

i haven't used MD5 (nor PGP/GPG, for that matter) to sign anything for
the purposes of non-repudiation, so i'm not freaked out about this.
the overall tone of these articles, however, is that MD5 is considered
at least "weakened" and we should not use it for any new documents or
standards.  the suggested replacements seem to be DSS/SHA-1,
RIPEMD-128, or RIPEMD-160, even if those are a little slower in
software.

for purposes such as tripwire, the use of multiple independent
checksums should make it that much harder to modify a file so that it
still generates the same CRC32, MD5, Adler-32 (?) and other checksums.
i suspect (but i haven't thought about it all *that* hard) that you
can concatenate all these checksums and treat the result as a
composite x-bit checksum, but there may be dependencies that seriously
reduce the actual amount of security we are getting.  i.e., CRC32 and
Adler32 both add 32 bits to this "composite hash", but if they both
rely purely on shifts and XORs, then they might not actually add a
full 64 bits of "new information" to the composite.

HTH,
t.