Re: md5 collision

Peter Pearson wrote:
> Pat Farrell wrote:
>> Based on MD5 in what way? Not in any technical aspect, other
>> than both were designed to be cryptographically strong hashes.
>
> The nature of the mushing, however, is very similar:
> a dataflow diagram of MD5 looks very much like a dataflow
> diagram of SHA.

Sure, they are both basically feisel ciphers.

Lots of ciphers are feisel ciphers, a dataflow diagram
doesn't show much. Take clear text, smush it some, end up
with weird garbage looking stuff.

Idea, AES, DES, lets look like that.

> Since SHA-1 appeared to be a very robust design, but has
> recently been found to be weak, the crypto community is
> perplexed by the realization that we don't know much about
> designing hash functions.

Found to have a flaw is not the same as "weak"
Which do you mean?

At some level, all crypto is voodoo.

--
Pat


.

Relevant Pages

  • Re: Comaprison between MD5 and SHA
    ... There is probably someway to take advantage of another core - but I doubt it ... At the point where you think MD5 could benefit from ... Then on the design side the C2D gets ... Both my E6300 and E6600 would overclock ...
    (sci.crypt)
  • Re: The modified MD5 data
    ... Other than the feedback mechanism MD5 isn't based on any really sound ... in theory" design. ... A clearly thought out easy to analyze design is always preferable. ... Yes, experimentation is good. ...
    (sci.crypt)
  • Re: Encrypting/Decrypting Password from a Config File
    ... Cracking MD5s isn't as easy as some people make it sound, ... If design A is better or equal to design B in all aspects, ... I never meant to imply "always use MD5 in your Java ...
    (comp.lang.java.programmer)
  • Re: md5 collision
    ... >> Because sha1 is closely based on MD5 it is no longer trusted. ... a dataflow diagram of MD5 looks very much like a dataflow ... Since SHA-1 appeared to be a very robust design, ... designing hash functions. ...
    (comp.os.linux.security)