MD5 Collisions Made Easy - Linux

This is a discussion on MD5 Collisions Made Easy - Linux ; http://th.informatik.uni-mannheim.de...ashCollisions/ "There have already been a few exploits of the collision-finding attacks against MD5: Kaminski [Ka] and Mikle [Mi] presented different executables with the same MD5 hash. One of Kaminski's executables was quite harmless, the other one very harmful. Mikle's ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 37

Thread: MD5 Collisions Made Easy

  1. MD5 Collisions Made Easy

    http://th.informatik.uni-mannheim.de...ashCollisions/


    "There have already been a few exploits of the collision-finding attacks
    against MD5: Kaminski [Ka] and Mikle [Mi] presented different executables
    with the same MD5 hash. One of Kaminski's executables was quite harmless,
    the other one very harmful. Mikle's executables were self-extracting
    archives, extracting different stuff. Lenstra, Wang and de Weger
    [LWdW,LdW] constructed colliding X.509 certificates."

    Il mittente di questo messaggio|The sender address of this
    non corrisponde ad un utente |message is not related to a real
    reale ma all'indirizzo fittizio|person but to a fake address of an
    di un sistema anonimizzatore |anonymous system
    Per maggiori informazioni |For more info
    https://www.mixmaster.it


  2. Re: MD5 Collisions Made Easy

    George Orwell wrote:

    > http://th.informatik.uni-mannheim.de...ashCollisions/
    >
    >
    > "There have already been a few exploits of the collision-finding attacks
    > against MD5: Kaminski [Ka] and Mikle [Mi] presented different executables
    > with the same MD5 hash. One of Kaminski's executables was quite harmless,
    > the other one very harmful. Mikle's executables were self-extracting
    > archives, extracting different stuff. Lenstra, Wang and de Weger
    > [LWdW,LdW] constructed colliding X.509 certificates."
    >


    Good. Now explain how that would enable any "forging" of ISOs

    Nobody claimed that there are no colision attacks possible on MD5. They are.

    Problem is: You need to control both files (the "untampered" one *and*
    the "tampered" one) to successfully forge MD5 hashes.

    This is old news, and it does not help MD5-dennis cause a tiny little bit.
    He is, and remains, a completely clueless nimwit, worthy to run Vista
    --
    Machine-Independent, adj.:
    Does not run on any existing machine.


  3. Re: MD5 Collisions Made Easy

    * Peter Köhlmann peremptorily fired off this memo:

    > This is old news, and it does not help MD5-dennis cause a tiny little bit.
    > He is, and remains, a completely clueless nimwit, worthy to run Vista


    He's baaaaaa-aaaaaack!

    --
    Reinvent yourself!
    -- Bill Gates

  4. Re: MD5 Collisions Made Easy

    Linonut writes:

    > * Peter Köhlmann peremptorily fired off this memo:
    >
    >> This is old news, and it does not help MD5-dennis cause a tiny little bit.
    >> He is, and remains, a completely clueless nimwit, worthy to run Vista

    >
    > He's baaaaaa-aaaaaack!


    We know you've become Roy's sheep but no need to make the same noises.

    --
    " Are there any decent document editors that can open ODT files except
    OpenOffice.org? oowriter is so unstable with large files that it would
    be funny if I didn't need to get this finished."

  5. Re: MD5 Collisions Made Easy

    On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:

    > Good. Now explain how that would enable any "forging" of ISOs
    >
    > Nobody claimed that there are no colision attacks possible on MD5. They are.
    >
    > Problem is: You need to control both files (the "untampered" one *and*
    > the "tampered" one) to successfully forge MD5 hashes.


    No you don't. You need only replace the ISO with a different ISO that's
    been specially designed to create the same MD5 hash as the original ISO.

    The way the hash collision exploits work is that you take an arbitrary file
    and add data to it to create a file that generates the same MD5 as a
    different file. This used to be considered too difficult to be plausible,
    but it's not anymore.

  6. Re: MD5 Collisions Made Easy

    In article ,
    Erik Funkenbusch wrote:
    > On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >
    > > Good. Now explain how that would enable any "forging" of ISOs
    > >
    > > Nobody claimed that there are no colision attacks possible on MD5. They are.
    > >
    > > Problem is: You need to control both files (the "untampered" one *and*
    > > the "tampered" one) to successfully forge MD5 hashes.

    >
    > No you don't. You need only replace the ISO with a different ISO that's
    > been specially designed to create the same MD5 hash as the original ISO.
    >
    > The way the hash collision exploits work is that you take an arbitrary file
    > and add data to it to create a file that generates the same MD5 as a
    > different file. This used to be considered too difficult to be plausible,
    > but it's not anymore.


    I believe that is not quite correct. You have to add data to *both*
    files. Given an existing file, that you cannot modify, generating
    another file that has the same MD5 hash is still infeasible.

    So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    your malware version and tweaking that to match the MD5. You have to be
    more subtle.


    --
    --Tim Smith

  7. Re: MD5 Collisions Made Easy

    Erik Funkenbusch wrote:

    > On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >
    >> Good. Now explain how that would enable any "forging" of ISOs
    >>
    >> Nobody claimed that there are no colision attacks possible on MD5. They
    >> are.
    >>
    >> Problem is: You need to control both files (the "untampered" one *and*
    >> the "tampered" one) to successfully forge MD5 hashes.

    >
    > No you don't. You need only replace the ISO with a different ISO that's
    > been specially designed to create the same MD5 hash as the original ISO.


    Fine, Erik. So you are another "MD5-dennis" nimwit, unaware of the workings
    of MD5. Do you happen to run Vista also, like that other dimwitted widiot?
    It seems to be a common trait among the more clueless posters around

    > The way the hash collision exploits work is that you take an arbitrary
    > file and add data to it to create a file that generates the same MD5 as a
    > different file. This used to be considered too difficult to be plausible,
    > but it's not anymore.


    Wrong as usual. When will you start to get /something/ right?
    You can create a collision attack on MD5 only if you have access to / own
    both files, as you need to change both of them.
    If it were as you say, MD5 would have to be dropped at once. As it isn't
    (and the collision flaw is known since quite some time already) this alone
    should tell you something

    This has been explained in detail several times, and as usual you are not
    smart enough to understand it. So it seems you really are a vista user
    --
    "Last I checked, it wasn't the power cord for the Clue Generator that
    was sticking up your ass." - John Novak, rasfwrj


  8. Re: MD5 Collisions Made Easy

    On Wed, 18 Jun 2008 11:23:07 -0700, Tim Smith
    wrote:

    >In article ,
    > Erik Funkenbusch wrote:
    >> On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >>
    >> > Good. Now explain how that would enable any "forging" of ISOs
    >> >
    >> > Nobody claimed that there are no colision attacks possible on MD5. They are.
    >> >
    >> > Problem is: You need to control both files (the "untampered" one *and*
    >> > the "tampered" one) to successfully forge MD5 hashes.

    >>
    >> No you don't. You need only replace the ISO with a different ISO that's
    >> been specially designed to create the same MD5 hash as the original ISO.
    >>
    >> The way the hash collision exploits work is that you take an arbitrary file
    >> and add data to it to create a file that generates the same MD5 as a
    >> different file. This used to be considered too difficult to be plausible,
    >> but it's not anymore.

    >
    >I believe that is not quite correct. You have to add data to *both*
    >files. Given an existing file, that you cannot modify, generating
    >another file that has the same MD5 hash is still infeasible.


    Do some research before spouting nonsense. You might even stumble upon
    small read-made compiled utilities that will make *any* file match
    *any* MD5.

    >
    >So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    >your malware version and tweaking that to match the MD5. You have to be
    >more subtle.


    No you don't. Script kiddies can do it.

  9. Re: MD5 Collisions Made Easy

    On Wed, 18 Jun 2008 11:23:07 -0700, Tim Smith wrote:

    > In article ,
    > Erik Funkenbusch wrote:
    >> On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >>
    >>> Good. Now explain how that would enable any "forging" of ISOs
    >>>
    >>> Nobody claimed that there are no colision attacks possible on MD5. They are.
    >>>
    >>> Problem is: You need to control both files (the "untampered" one *and*
    >>> the "tampered" one) to successfully forge MD5 hashes.

    >>
    >> No you don't. You need only replace the ISO with a different ISO that's
    >> been specially designed to create the same MD5 hash as the original ISO.
    >>
    >> The way the hash collision exploits work is that you take an arbitrary file
    >> and add data to it to create a file that generates the same MD5 as a
    >> different file. This used to be considered too difficult to be plausible,
    >> but it's not anymore.

    >
    > I believe that is not quite correct. You have to add data to *both*
    > files. Given an existing file, that you cannot modify, generating
    > another file that has the same MD5 hash is still infeasible.
    >
    > So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    > your malware version and tweaking that to match the MD5. You have to be
    > more subtle.


    That makes no sense. You don't need to add data to the original file
    because it's already got the correct MD5, the whole point of the exploit is
    to create a new file that contains arbitrary data that has the same MD5.
    Then you replace the original file with your new one and nobody is the
    wiser because the MD5 has stayed the same.

  10. Re: MD5 Collisions Made Easy

    On Wed, 18 Jun 2008 21:08:03 +0200, Peter Köhlmann wrote:

    > Erik Funkenbusch wrote:
    >
    >> On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >>
    >>> Good. Now explain how that would enable any "forging" of ISOs
    >>>
    >>> Nobody claimed that there are no colision attacks possible on MD5. They
    >>> are.
    >>>
    >>> Problem is: You need to control both files (the "untampered" one *and*
    >>> the "tampered" one) to successfully forge MD5 hashes.

    >>
    >> No you don't. You need only replace the ISO with a different ISO that's
    >> been specially designed to create the same MD5 hash as the original ISO.

    >
    > Fine, Erik. So you are another "MD5-dennis" nimwit, unaware of the workings
    > of MD5. Do you happen to run Vista also, like that other dimwitted widiot?
    > It seems to be a common trait among the more clueless posters around
    >
    >> The way the hash collision exploits work is that you take an arbitrary
    >> file and add data to it to create a file that generates the same MD5 as a
    >> different file. This used to be considered too difficult to be plausible,
    >> but it's not anymore.

    >
    > Wrong as usual. When will you start to get /something/ right?
    > You can create a collision attack on MD5 only if you have access to / own
    > both files, as you need to change both of them.
    > If it were as you say, MD5 would have to be dropped at once. As it isn't
    > (and the collision flaw is known since quite some time already) this alone
    > should tell you something
    >
    > This has been explained in detail several times, and as usual you are not
    > smart enough to understand it. So it seems you really are a vista user


    Modifying the original file makes no sense, because the goal of the exploit
    is to replace the original file with a new one with the same MD5.

  11. Re: MD5 Collisions Made Easy

    OK wrote:

    > On Wed, 18 Jun 2008 11:23:07 -0700, Tim Smith
    > wrote:
    >
    >>In article ,
    >> Erik Funkenbusch wrote:
    >>> On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >>>
    >>> > Good. Now explain how that would enable any "forging" of ISOs
    >>> >
    >>> > Nobody claimed that there are no colision attacks possible on MD5.
    >>> > They are.
    >>> >
    >>> > Problem is: You need to control both files (the "untampered" one *and*
    >>> > the "tampered" one) to successfully forge MD5 hashes.
    >>>
    >>> No you don't. You need only replace the ISO with a different ISO that's
    >>> been specially designed to create the same MD5 hash as the original ISO.
    >>>
    >>> The way the hash collision exploits work is that you take an arbitrary
    >>> file and add data to it to create a file that generates the same MD5 as
    >>> a
    >>> different file. This used to be considered too difficult to be
    >>> plausible, but it's not anymore.

    >>
    >>I believe that is not quite correct. You have to add data to *both*
    >>files. Given an existing file, that you cannot modify, generating
    >>another file that has the same MD5 hash is still infeasible.

    >
    > Do some research before spouting nonsense. You might even stumble upon
    > small read-made compiled utilities that will make *any* file match
    > *any* MD5.


    Fine. As you are so adept at finding stuff like that, you will certainly
    point the "mere mortals" to those "fairy dust tools"

    >>
    >>So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    >>your malware version and tweaking that to match the MD5. You have to be
    >>more subtle.

    >
    > No you don't. Script kiddies can do it.


    Oh gods, Otto Kaiser is still around to show that, when you think it can't
    get any dumber, he proves that it well can be

    --
    A NT server can be run by idiots and usually is


  12. Re: MD5 Collisions Made Easy

    Erik Funkenbusch wrote:

    > On Wed, 18 Jun 2008 21:08:03 +0200, Peter Köhlmann wrote:
    >
    >> Erik Funkenbusch wrote:
    >>
    >>> On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >>>
    >>>> Good. Now explain how that would enable any "forging" of ISOs
    >>>>
    >>>> Nobody claimed that there are no colision attacks possible on MD5. They
    >>>> are.
    >>>>
    >>>> Problem is: You need to control both files (the "untampered" one *and*
    >>>> the "tampered" one) to successfully forge MD5 hashes.
    >>>
    >>> No you don't. You need only replace the ISO with a different ISO that's
    >>> been specially designed to create the same MD5 hash as the original ISO.

    >>
    >> Fine, Erik. So you are another "MD5-dennis" nimwit, unaware of the
    >> workings of MD5. Do you happen to run Vista also, like that other
    >> dimwitted widiot? It seems to be a common trait among the more clueless
    >> posters around
    >>
    >>> The way the hash collision exploits work is that you take an arbitrary
    >>> file and add data to it to create a file that generates the same MD5 as
    >>> a
    >>> different file. This used to be considered too difficult to be
    >>> plausible, but it's not anymore.

    >>
    >> Wrong as usual. When will you start to get /something/ right?
    >> You can create a collision attack on MD5 only if you have access to / own
    >> both files, as you need to change both of them.
    >> If it were as you say, MD5 would have to be dropped at once. As it isn't
    >> (and the collision flaw is known since quite some time already) this
    >> alone should tell you something
    >>
    >> This has been explained in detail several times, and as usual you are not
    >> smart enough to understand it. So it seems you really are a vista user

    >
    > Modifying the original file makes no sense, because the goal of the
    > exploit is to replace the original file with a new one with the same MD5.


    Good. Then tell us *how*
    Before you show again your utter ignorance or do another "Otto Kaiser
    idiocy", read up on "collision attack" and "pre-image attack" on MD5

    You /can/ use simple google searches, right, Erik?
    --
    Microsoft: which revised Eula do you want to accept today?


  13. Re: MD5 Collisions Made Easy

    Erik Funkenbusch wrote:

    > On Wed, 18 Jun 2008 11:23:07 -0700, Tim Smith wrote:
    >
    >> In article ,
    >> Erik Funkenbusch wrote:
    >>> On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >>>
    >>>> Good. Now explain how that would enable any "forging" of ISOs
    >>>>
    >>>> Nobody claimed that there are no colision attacks possible on MD5. They
    >>>> are.
    >>>>
    >>>> Problem is: You need to control both files (the "untampered" one *and*
    >>>> the "tampered" one) to successfully forge MD5 hashes.
    >>>
    >>> No you don't. You need only replace the ISO with a different ISO that's
    >>> been specially designed to create the same MD5 hash as the original ISO.
    >>>
    >>> The way the hash collision exploits work is that you take an arbitrary
    >>> file and add data to it to create a file that generates the same MD5 as
    >>> a
    >>> different file. This used to be considered too difficult to be
    >>> plausible, but it's not anymore.

    >>
    >> I believe that is not quite correct. You have to add data to *both*
    >> files. Given an existing file, that you cannot modify, generating
    >> another file that has the same MD5 hash is still infeasible.
    >>
    >> So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    >> your malware version and tweaking that to match the MD5. You have to be
    >> more subtle.

    >
    > That makes no sense. You don't need to add data to the original file
    > because it's already got the correct MD5, the whole point of the exploit
    > is to create a new file that contains arbitrary data that has the same
    > MD5. Then you replace the original file with your new one and nobody is
    > the wiser because the MD5 has stayed the same.


    Poor Erik. Should you now call yourself "Otto Kaiser" because you are so
    utterly clueless or will "Funkenbusch" still do?
    --
    Windows: Because everyone needs a good laugh!


  14. Re: MD5 Collisions Made Easy

    Peter Köhlmann writes:

    > Erik Funkenbusch wrote:
    >
    >> On Wed, 18 Jun 2008 11:23:07 -0700, Tim Smith wrote:
    >>
    >>> In article ,
    >>> Erik Funkenbusch wrote:
    >>>> On Wed, 18 Jun 2008 15:36:27 +0200, Peter Köhlmann wrote:
    >>>>
    >>>>> Good. Now explain how that would enable any "forging" of ISOs
    >>>>>
    >>>>> Nobody claimed that there are no colision attacks possible on MD5. They
    >>>>> are.
    >>>>>
    >>>>> Problem is: You need to control both files (the "untampered" one *and*
    >>>>> the "tampered" one) to successfully forge MD5 hashes.
    >>>>
    >>>> No you don't. You need only replace the ISO with a different ISO that's
    >>>> been specially designed to create the same MD5 hash as the original ISO.
    >>>>
    >>>> The way the hash collision exploits work is that you take an arbitrary
    >>>> file and add data to it to create a file that generates the same MD5 as
    >>>> a
    >>>> different file. This used to be considered too difficult to be
    >>>> plausible, but it's not anymore.
    >>>
    >>> I believe that is not quite correct. You have to add data to *both*
    >>> files. Given an existing file, that you cannot modify, generating
    >>> another file that has the same MD5 hash is still infeasible.
    >>>
    >>> So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    >>> your malware version and tweaking that to match the MD5. You have to be
    >>> more subtle.

    >>
    >> That makes no sense. You don't need to add data to the original file
    >> because it's already got the correct MD5, the whole point of the exploit
    >> is to create a new file that contains arbitrary data that has the same
    >> MD5. Then you replace the original file with your new one and nobody is
    >> the wiser because the MD5 has stayed the same.

    >
    > Poor Erik. Should you now call yourself "Otto Kaiser" because you are so
    > utterly clueless or will "Funkenbusch" still do?


    He's back. And he's angry!

    God bless the Germans and their patience with others!

    Rick and Roy will be getting all excited now the heavy cavalry is back
    in town with Sabre swinging and pointy helmet firmly fixed on top of his
    humongus anti-aliased head!

    --
    XP is a flop and when users are still asking for W98 it shows that they
    aren't all taken in with the MS hype.
    comp.os.linux.advocacy - where they put the lunacy in advocacy

  15. Re: MD5 Collisions Made Easy

    In article ,
    OK wrote:
    > >
    > >I believe that is not quite correct. You have to add data to *both*
    > >files. Given an existing file, that you cannot modify, generating
    > >another file that has the same MD5 hash is still infeasible.

    >
    > Do some research before spouting nonsense. You might even stumble upon
    > small read-made compiled utilities that will make *any* file match
    > *any* MD5.


    Interesting that those utilities have *completely* escaped the notice of
    the cryptographic community. The state of the art currently allows
    generating pairs of files with matching MD5 sums.

    There's no publicly known method significantly better than brute force
    for finding a file whose MD5 matches a given file.

    --
    --Tim Smith

  16. Re: MD5 Collisions Made Easy

    In article <1op1kw1zje0a7.dlg@funkenbusch.com>,
    Erik Funkenbusch wrote:
    > >> The way the hash collision exploits work is that you take an arbitrary
    > >> file
    > >> and add data to it to create a file that generates the same MD5 as a
    > >> different file. This used to be considered too difficult to be plausible,
    > >> but it's not anymore.

    > >
    > > I believe that is not quite correct. You have to add data to *both*
    > > files. Given an existing file, that you cannot modify, generating
    > > another file that has the same MD5 hash is still infeasible.
    > >
    > > So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    > > your malware version and tweaking that to match the MD5. You have to be
    > > more subtle.

    >
    > That makes no sense. You don't need to add data to the original file
    > because it's already got the correct MD5, the whole point of the exploit is
    > to create a new file that contains arbitrary data that has the same MD5.
    > Then you replace the original file with your new one and nobody is the
    > wiser because the MD5 has stayed the same.


    Nope. Given an existing file, there is no known method (other than
    brute force) to generate a second file with the same MD5 sum.

    What is known is a way to generate two new files that have the same sum
    as each other.

    This has been exploited to produce two PDF files containing messages
    with opposite meaning, that have the same MD5 sum. Note that this means
    that if you used a digital signature scheme that involved signing an MD5
    of the message, a signature for one of the messages would also be a
    signature for the other message.

    Similar collisions have been found in other hashes, and so the net
    result is that you should never digitally sign something that you did
    not generate. If someone gives you a file to sign, add some
    unpredictable text to it first, so that if they prepared an opposite
    document, you won't be signing that too.

    Net result: if you trust the person that produced the ISO on the
    official download site, so that you are sure they did not also prepare a
    bad ISO, then you can trust the MD5. A third party will not be able to
    make an ISO that matches it.

    --
    --Tim Smith

  17. Re: MD5 Collisions Made Easy


    "Tim Smith" wrote in message
    news:reply_in_group-53E8AB.13103418062008@sn-indi.vsrv-sjc.supernews.net...
    > In article <1op1kw1zje0a7.dlg@funkenbusch.com>,
    > Erik Funkenbusch wrote:
    >> >> The way the hash collision exploits work is that you take an arbitrary
    >> >> file
    >> >> and add data to it to create a file that generates the same MD5 as a
    >> >> different file. This used to be considered too difficult to be
    >> >> plausible,
    >> >> but it's not anymore.
    >> >
    >> > I believe that is not quite correct. You have to add data to *both*
    >> > files. Given an existing file, that you cannot modify, generating
    >> > another file that has the same MD5 hash is still infeasible.
    >> >
    >> > So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    >> > your malware version and tweaking that to match the MD5. You have to
    >> > be
    >> > more subtle.

    >>
    >> That makes no sense. You don't need to add data to the original file
    >> because it's already got the correct MD5, the whole point of the exploit
    >> is
    >> to create a new file that contains arbitrary data that has the same MD5.
    >> Then you replace the original file with your new one and nobody is the
    >> wiser because the MD5 has stayed the same.

    >
    > Nope. Given an existing file, there is no known method (other than
    > brute force) to generate a second file with the same MD5 sum.


    I'm not a crypto guru and know little about md5 other than I use it to
    generate hashes. But I ran across this which looks interesting. Perhaps you
    can comment.

    - ss


    http://www.win.tue.nl/hashclash/fastcoll.pdf


    --- "For arbitrary random initial values the average is about 5 minutes
    (avg. complexity 234.1). With a reasonable probability a collision is found
    within mere seconds, allowing for instance an attack during the execution of
    a protocol.


    Conclusion - Our presented algorithm together with new conditions we've
    found allows us to find full MD5collisions in only minutes on a 3Ghz
    Pentium4. We have shown that the initial value for theattack can have a
    significant impact in the average complexity of MD5 collision finding.
    Using2 conditions on the initial value to avoid very hard situations we
    reduce our average running timeto 67 seconds. Also with reasonable
    probability a collision can be found in mere seconds, which allows collision
    finding during a protocol execution."



    > What is known is a way to generate two new files that have the same sum
    > as each other.
    >
    > This has been exploited to produce two PDF files containing messages
    > with opposite meaning, that have the same MD5 sum. Note that this means
    > that if you used a digital signature scheme that involved signing an MD5
    > of the message, a signature for one of the messages would also be a
    > signature for the other message.
    >
    > Similar collisions have been found in other hashes, and so the net
    > result is that you should never digitally sign something that you did
    > not generate. If someone gives you a file to sign, add some
    > unpredictable text to it first, so that if they prepared an opposite
    > document, you won't be signing that too.
    >
    > Net result: if you trust the person that produced the ISO on the
    > official download site, so that you are sure they did not also prepare a
    > bad ISO, then you can trust the MD5. A third party will not be able to
    > make an ISO that matches it.
    >
    > --
    > --Tim Smith




  18. Re: MD5 Collisions Made Easy

    Subway steel wrote:

    >
    > "Tim Smith" wrote in message
    >

    news:reply_in_group-53E8AB.13103418062008@sn-indi.vsrv-sjc.supernews.net...
    >> In article <1op1kw1zje0a7.dlg@funkenbusch.com>,
    >> Erik Funkenbusch wrote:
    >>> >> The way the hash collision exploits work is that you take an
    >>> >> arbitrary file
    >>> >> and add data to it to create a file that generates the same MD5 as a
    >>> >> different file. This used to be considered too difficult to be
    >>> >> plausible,
    >>> >> but it's not anymore.
    >>> >
    >>> > I believe that is not quite correct. You have to add data to *both*
    >>> > files. Given an existing file, that you cannot modify, generating
    >>> > another file that has the same MD5 hash is still infeasible.
    >>> >
    >>> > So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    >>> > your malware version and tweaking that to match the MD5. You have to
    >>> > be
    >>> > more subtle.
    >>>
    >>> That makes no sense. You don't need to add data to the original file
    >>> because it's already got the correct MD5, the whole point of the exploit
    >>> is
    >>> to create a new file that contains arbitrary data that has the same MD5.
    >>> Then you replace the original file with your new one and nobody is the
    >>> wiser because the MD5 has stayed the same.

    >>
    >> Nope. Given an existing file, there is no known method (other than
    >> brute force) to generate a second file with the same MD5 sum.

    >
    > I'm not a crypto guru and know little about md5 other than I use it to
    > generate hashes. But I ran across this which looks interesting. Perhaps
    > you can comment.
    >
    > - ss
    >
    >
    > http://www.win.tue.nl/hashclash/fastcoll.pdf
    >
    >
    > --- "For arbitrary random initial values the average is about 5 minutes
    > (avg. complexity 234.1). With a reasonable probability a collision is
    > found within mere seconds, allowing for instance an attack during the
    > execution of a protocol.
    >
    >
    > Conclusion - Our presented algorithm together with new conditions we've
    > found allows us to find full MD5collisions in only minutes on a 3Ghz
    > Pentium4. We have shown that the initial value for theattack can have a
    > significant impact in the average complexity of MD5 collision finding.
    > Using2 conditions on the initial value to avoid very hard situations we
    > reduce our average running timeto 67 seconds. Also with reasonable
    > probability a collision can be found in mere seconds, which allows
    > collision finding during a protocol execution."
    >


    You posted it yourself, naturally without the tiniest shred of understanding
    it.
    It mentioned "collisions". Now do yourself a favour. Read up on "collision
    attacks" on MD5. And what they constitute.

    Hint: It is not anything near what you think they are. Don't be another Otto
    Kaiser. Or another Erik Funkenbusch. Or another MD5-dennis.

    There are enough clueless nimwits running vista around. No neeed to add
    another one
    --
    Don't steal. Microsoft hates competition.


  19. Re: MD5 Collisions Made Easy

    Peter Köhlmann writes:

    > Subway steel wrote:
    >
    >>
    >> "Tim Smith" wrote in message
    >>

    > news:reply_in_group-53E8AB.13103418062008@sn-indi.vsrv-sjc.supernews.net...
    >>> In article <1op1kw1zje0a7.dlg@funkenbusch.com>,
    >>> Erik Funkenbusch wrote:
    >>>> >> The way the hash collision exploits work is that you take an
    >>>> >> arbitrary file
    >>>> >> and add data to it to create a file that generates the same MD5 as a
    >>>> >> different file. This used to be considered too difficult to be
    >>>> >> plausible,
    >>>> >> but it's not anymore.
    >>>> >
    >>>> > I believe that is not quite correct. You have to add data to *both*
    >>>> > files. Given an existing file, that you cannot modify, generating
    >>>> > another file that has the same MD5 hash is still infeasible.
    >>>> >
    >>>> > So, exploiting MD5 is not as easy as just grabbing an ISO, and making
    >>>> > your malware version and tweaking that to match the MD5. You have to
    >>>> > be
    >>>> > more subtle.
    >>>>
    >>>> That makes no sense. You don't need to add data to the original file
    >>>> because it's already got the correct MD5, the whole point of the exploit
    >>>> is
    >>>> to create a new file that contains arbitrary data that has the same MD5.
    >>>> Then you replace the original file with your new one and nobody is the
    >>>> wiser because the MD5 has stayed the same.
    >>>
    >>> Nope. Given an existing file, there is no known method (other than
    >>> brute force) to generate a second file with the same MD5 sum.

    >>
    >> I'm not a crypto guru and know little about md5 other than I use it to
    >> generate hashes. But I ran across this which looks interesting. Perhaps
    >> you can comment.
    >>
    >> - ss
    >>
    >>
    >> http://www.win.tue.nl/hashclash/fastcoll.pdf
    >>
    >>
    >> --- "For arbitrary random initial values the average is about 5 minutes
    >> (avg. complexity 234.1). With a reasonable probability a collision is
    >> found within mere seconds, allowing for instance an attack during the
    >> execution of a protocol.
    >>
    >>
    >> Conclusion - Our presented algorithm together with new conditions we've
    >> found allows us to find full MD5collisions in only minutes on a 3Ghz
    >> Pentium4. We have shown that the initial value for theattack can have a
    >> significant impact in the average complexity of MD5 collision finding.
    >> Using2 conditions on the initial value to avoid very hard situations we
    >> reduce our average running timeto 67 seconds. Also with reasonable
    >> probability a collision can be found in mere seconds, which allows
    >> collision finding during a protocol execution."
    >>

    >
    > You posted it yourself, naturally without the tiniest shred of understanding
    > it.
    > It mentioned "collisions". Now do yourself a favour. Read up on "collision
    > attacks" on MD5. And what they constitute.
    >
    > Hint: It is not anything near what you think they are. Don't be another Otto
    > Kaiser. Or another Erik Funkenbusch. Or another MD5-dennis.
    >
    > There are enough clueless nimwits running vista around. No neeed to add
    > another one


    So you were a clueless idiot when you told us swapfiles were no where
    near as efficient as partitions in modern kernels? Or that you can not
    see AA working on a snapshot image?

    Thanks for confirmation.

    The group was more informed without you.

    --
    XP is a flop and when users are still asking for W98 it shows that they
    aren't all taken in with the MS hype.
    comp.os.linux.advocacy - where they put the lunacy in advocacy

  20. Re: MD5 Collisions Made Easy

    Hadron wrote:

    > Peter Köhlmann writes:
    >
    >> Subway steel wrote:
    >>
    >>>
    >>> "Tim Smith" wrote in message
    >>>

    >>

    news:reply_in_group-53E8AB.13103418062008@sn-indi.vsrv-sjc.supernews.net...
    >>>> In article <1op1kw1zje0a7.dlg@funkenbusch.com>,
    >>>> Erik Funkenbusch wrote:
    >>>>> >> The way the hash collision exploits work is that you take an
    >>>>> >> arbitrary file
    >>>>> >> and add data to it to create a file that generates the same MD5 as
    >>>>> >> a
    >>>>> >> different file. This used to be considered too difficult to be
    >>>>> >> plausible,
    >>>>> >> but it's not anymore.
    >>>>> >
    >>>>> > I believe that is not quite correct. You have to add data to *both*
    >>>>> > files. Given an existing file, that you cannot modify, generating
    >>>>> > another file that has the same MD5 hash is still infeasible.
    >>>>> >
    >>>>> > So, exploiting MD5 is not as easy as just grabbing an ISO, and
    >>>>> > making
    >>>>> > your malware version and tweaking that to match the MD5. You have
    >>>>> > to be
    >>>>> > more subtle.
    >>>>>
    >>>>> That makes no sense. You don't need to add data to the original file
    >>>>> because it's already got the correct MD5, the whole point of the
    >>>>> exploit is
    >>>>> to create a new file that contains arbitrary data that has the same
    >>>>> MD5. Then you replace the original file with your new one and nobody
    >>>>> is the wiser because the MD5 has stayed the same.
    >>>>
    >>>> Nope. Given an existing file, there is no known method (other than
    >>>> brute force) to generate a second file with the same MD5 sum.
    >>>
    >>> I'm not a crypto guru and know little about md5 other than I use it to
    >>> generate hashes. But I ran across this which looks interesting. Perhaps
    >>> you can comment.
    >>>
    >>> - ss
    >>>
    >>>
    >>> http://www.win.tue.nl/hashclash/fastcoll.pdf
    >>>
    >>>
    >>> --- "For arbitrary random initial values the average is about 5 minutes
    >>> (avg. complexity 234.1). With a reasonable probability a collision is
    >>> found within mere seconds, allowing for instance an attack during the
    >>> execution of a protocol.
    >>>
    >>>
    >>> Conclusion - Our presented algorithm together with new conditions we've
    >>> found allows us to find full MD5collisions in only minutes on a 3Ghz
    >>> Pentium4. We have shown that the initial value for theattack can have a
    >>> significant impact in the average complexity of MD5 collision finding.
    >>> Using2 conditions on the initial value to avoid very hard situations we
    >>> reduce our average running timeto 67 seconds. Also with reasonable
    >>> probability a collision can be found in mere seconds, which allows
    >>> collision finding during a protocol execution."
    >>>

    >>
    >> You posted it yourself, naturally without the tiniest shred of
    >> understanding it.
    >> It mentioned "collisions". Now do yourself a favour. Read up on
    >> "collision attacks" on MD5. And what they constitute.
    >>
    >> Hint: It is not anything near what you think they are. Don't be another
    >> Otto Kaiser. Or another Erik Funkenbusch. Or another MD5-dennis.
    >>
    >> There are enough clueless nimwits running vista around. No neeed to add
    >> another one

    >
    > So you were a clueless idiot when you told us swapfiles were no where
    > near as efficient as partitions in modern kernels? Or that you can not
    > see AA working on a snapshot image?
    >
    > Thanks for confirmation.
    >
    > The group was more informed without you.
    >


    Leave it to Hadron Quark to "defend" clueless nimwits with something which
    has *nothing* at all to do with the subject at hand, even if it were true

    Well done, "true linux advocate" Hadron Quark. Showing your true colours
    again in all their "glory"
    --
    It's sweet to be remembered, but it's often cheaper to be forgotten.


+ Reply to Thread
Page 1 of 2 1 2 LastLast