md5 collision - Security

This is a discussion on md5 collision - Security ; What encription algorithm should i use for replacing the md5 for hasing?I understand that it was release the source code of the application that could make md5 collision Best regards, julissa.leones@realcredits.com master@poweroversoftware.com http://www.poweroversoftware.com...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 77

Thread: md5 collision

  1. md5 collision

    What encription algorithm should i use for replacing the md5 for hasing?I understand that it was release the source code of the application that could make md5 collision


    Best regards,
    julissa.leones@realcredits.com
    master@poweroversoftware.com
    http://www.poweroversoftware.com

  2. Re: md5 collision

    julissa.leones@booomail.com wrote:

    > What encription algorithm should i use for replacing the md5 for
    > hasing?I understand that it was release the source code of the
    > application that could make md5 collision


    The best alternative at present is SHA256. If you want
    less than 256 bits of hash, compute SHA256 and truncate
    the result.

    Note that the ability to produce collision pairs for MD5
    is *not* fatal for applications like (1) password hashing
    or (2) confirming that downloaded software matches the
    official distribution, since both these uses
    depend on the difficulty of finding a pre-image
    for a specific hash.

    --
    Peter Pearson
    To get my email address, substitute:
    nowhere -> spamcop, invalid -> net


  3. Re: md5 collision

    julissa.leones@booomail.com writes:

    > What encription algorithm should i use for replacing the md5 for hasing?I understand that it was release the source code of the application that could make md5 collision



    A little knowledge is a dangerous thing.
    a) Linux does NOT password hash with MD5. It uses a horribly convoluted hash
    function which uses md5 amongst many other things to create the hash.
    b)One cannot create collisions. One can generate two files which have the
    same md5 hash. One cannot create a second file with the same md5 hash as
    a given file.
    c) If you want to use the hash for other purposes, the recommendation is to
    use sha256.


  4. Re: md5 collision

    * Unruh
    | b)One cannot create collisions. One can generate two files which
    | have the same md5 hash. One cannot create a second file with the
    | same md5 hash as a given file.

    Care to re-phrase? The last two sentences contradict each other in my
    understanding if interpreted literally.

    | One can generate two files which have the same md5 hash.

    Copy the file and it will have the same hash (of course)?

    | One cannot create a second file with the same md5 hash as a given
    | file.

    I just did? Or do you (obviously?) mean 'a second file with different
    contents than the first one'?

    R'

  5. Re: md5 collision

    julissa.leones@booomail.com wrote:
    > What encription algorithm should i use for replacing the md5 for
    > hasing?


    SHA, depending on the security needed, SHA1 may be fine
    if not SHA256
    source code and test vectors are readily availble.


    --
    Pat



  6. Re: md5 collision

    Ralf Fassel writes:

    >* Unruh
    >| b)One cannot create collisions. One can generate two files which
    >| have the same md5 hash. One cannot create a second file with the
    >| same md5 hash as a given file.


    >Care to re-phrase? The last two sentences contradict each other in my
    >understanding if interpreted literally.


    No they do not. In the first case, you can create two files which have the
    same md5. In the second you are given a file and you have to find another
    one with the same md5. In the first case neither of the two files is known
    beforehand. In the second one is.
    Now, it is not as inoccuous as it sounds. Since you can also take two given
    files and all stuff to the end of them such that the two ammended files
    have the same md5. thus one could say "I agree to pay you $10 $ and the
    other "I agree to pay you $1000" afterwards, the two read

    "I agree to pay you $10



    ^&^^%KJSH*(*"

    and the other reads

    "I agree to pay you $1000


    NLK<>&*(^&)(*P> "
    and that junk could be hidden in the huge amount to junk that Word for
    example stores in the file.



    >| One can generate two files which have the same md5 hash.


    >Copy the file and it will have the same hash (of course)?


    >| One cannot create a second file with the same md5 hash as a given
    >| file.


    >I just did? Or do you (obviously?) mean 'a second file with different
    >contents than the first one'?


    >R'


  7. Re: md5 collision

    Pat Farrell writes:

    >julissa.leones@booomail.com wrote:
    >> What encription algorithm should i use for replacing the md5 for
    >> hasing?


    >SHA, depending on the security needed, SHA1 may be fine
    >if not SHA256
    >source code and test vectors are readily availble.


    Because sha1 is closely based on MD5 it is no longer trusted.
    sha256 is recommended. Despite similar names, the algorithm is very
    different as I understand.



  8. Re: md5 collision

    Unruh wrote:

    > In the first case neither of the two files is known
    > beforehand. In the second one is.


    When dealing with the first case, you create the first of the two files,
    then the file IS known. Then you would be dealing with the second case.
    Unless you create both files at the same time, there is no way the first
    case can happen. You will always have a known file after the creation of
    the first file and only the second case would be applicable after the
    creation of the first file.

  9. Re: md5 collision

    matt_left_coast writes:

    >Unruh wrote:


    >> In the first case neither of the two files is known
    >> beforehand. In the second one is.


    >When dealing with the first case, you create the first of the two files,
    >then the file IS known. Then you would be dealing with the second case.


    But you have to create them together. You cannot create one and then make
    another which has the same md5.

    >Unless you create both files at the same time, there is no way the first


    YOu have to create them at the same time for the break to work. Ie, the
    break uses both files in creating the break.


    >case can happen. You will always have a known file after the creation of
    >the first file and only the second case would be applicable after the
    >creation of the first file.


    No. You must create both at the same time.
    Eg, lets say you take the MD5 of the first file and place that byte at the end of the second,
    then take the md5 of the second (including the added byte) and place one byte of that at the end of
    the first file, etc for 100 steps. (This is NOT how it is done but it
    illustrates how you can have to create both files at the same time.)


  10. Re: md5 collision

    Unruh wrote:

    >>When dealing with the first case, you create the first of the two files,
    >>then the file IS known. Then you would be dealing with the second case.

    >
    > But you have to create them together. You cannot create one and then make
    > another which has the same md5.


    Exact process please.

    --



  11. Re: md5 collision

    Unruh wrote:

    >>When dealing with the first case, you create the first of the two files,
    >>then the file IS known. Then you would be dealing with the second case.

    >
    > But you have to create them together. You cannot create one and then make
    > another which has the same md5.


    Exact process, please.

    --



  12. Re: md5 collision

    matt_left_coast writes:

    >Unruh wrote:


    >>>When dealing with the first case, you create the first of the two files,
    >>>then the file IS known. Then you would be dealing with the second case.

    >>
    >> But you have to create them together. You cannot create one and then make
    >> another which has the same md5.


    >Exact process, please.


    Go read the papers.




  13. Re: md5 collision

    Unruh wrote:

    > Pat Farrell writes:
    >
    >>julissa.leones@booomail.com wrote:
    >>> What encription algorithm should i use for replacing the md5 for
    >>> hasing?

    >
    >>SHA, depending on the security needed, SHA1 may be fine
    >>if not SHA256
    >>source code and test vectors are readily availble.

    >
    > Because sha1 is closely based on MD5 it is no longer trusted.
    > sha256 is recommended. Despite similar names, the algorithm is very
    > different as I understand.


    Based on MD5 in what way? Not in any technical aspect, other
    than both were designed to be cryptographically strong hashes.

    Compared to MD5? hardly.
    There are published theoretical attacks on SHA1.

    Depends on the attack model.

    --
    Pat



  14. Re: md5 collision

    Unruh wrote:

    > matt_left_coast writes:
    >
    >>Unruh wrote:

    >
    >>>>When dealing with the first case, you create the first of the two files,
    >>>>then the file IS known. Then you would be dealing with the second case.
    >>>
    >>> But you have to create them together. You cannot create one and then
    >>> make another which has the same md5.

    >
    >>Exact process, please.

    >
    > Go read the papers.


    Well, I'll take that as proof you are just bull ****ting, as I thought.

    --



  15. Re: md5 collision

    matt_left_coast wrote:
    > Unruh wrote:
    >
    >
    >>matt_left_coast writes:
    >>
    >>
    >>>Unruh wrote:

    >>
    >>>>>When dealing with the first case, you create the first of the two files,
    >>>>>then the file IS known. Then you would be dealing with the second case.
    >>>>
    >>>>But you have to create them together. You cannot create one and then
    >>>>make another which has the same md5.

    >>
    >>>Exact process, please.

    >>
    >>Go read the papers.

    >
    >
    > Well, I'll take that as proof you are just bull ****ting, as I thought.
    >

    Is it proof of the same thing when you do it?

    You seem to do it alot

  16. Re: md5 collision

    Jan Pompe wrote:

    > matt_left_coast wrote:
    >> Unruh wrote:
    >>
    >>
    >>>matt_left_coast writes:
    >>>
    >>>
    >>>>Unruh wrote:
    >>>
    >>>>>>When dealing with the first case, you create the first of the two
    >>>>>>files, then the file IS known. Then you would be dealing with the
    >>>>>>second case.
    >>>>>
    >>>>>But you have to create them together. You cannot create one and then
    >>>>>make another which has the same md5.
    >>>
    >>>>Exact process, please.
    >>>
    >>>Go read the papers.

    >>
    >>
    >> Well, I'll take that as proof you are just bull ****ting, as I thought.
    >>

    > Is it proof of the same thing when you do it?
    >
    > You seem to do it alot


    Where?

    --



  17. Re: md5 collision

    matt_left_coast wrote:
    > Jan Pompe wrote:
    >
    >
    >>matt_left_coast wrote:
    >>
    >>>Unruh wrote:
    >>>
    >>>
    >>>
    >>>>matt_left_coast writes:
    >>>>
    >>>>
    >>>>
    >>>>>Unruh wrote:
    >>>>
    >>>>>>>When dealing with the first case, you create the first of the two
    >>>>>>>files, then the file IS known. Then you would be dealing with the
    >>>>>>>second case.
    >>>>>>
    >>>>>>But you have to create them together. You cannot create one and then
    >>>>>>make another which has the same md5.
    >>>>
    >>>>>Exact process, please.
    >>>>
    >>>>Go read the papers.
    >>>
    >>>
    >>>Well, I'll take that as proof you are just bull ****ting, as I thought.
    >>>

    >>
    >>Is it proof of the same thing when you do it?
    >>
    >>You seem to do it alot

    >
    >
    > Where?
    >

    Do you have a problem with recall?

    here, wish list overcoming NIS
    here there everywhere

  18. Re: md5 collision

    Jan Pompe wrote:

    > matt_left_coast wrote:
    >> Jan Pompe wrote:
    >>
    >>
    >>>matt_left_coast wrote:
    >>>
    >>>>Unruh wrote:
    >>>>
    >>>>
    >>>>
    >>>>>matt_left_coast writes:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>Unruh wrote:
    >>>>>
    >>>>>>>>When dealing with the first case, you create the first of the two
    >>>>>>>>files, then the file IS known. Then you would be dealing with the
    >>>>>>>>second case.
    >>>>>>>
    >>>>>>>But you have to create them together. You cannot create one and then
    >>>>>>>make another which has the same md5.
    >>>>>
    >>>>>>Exact process, please.
    >>>>>
    >>>>>Go read the papers.
    >>>>
    >>>>
    >>>>Well, I'll take that as proof you are just bull ****ting, as I thought.
    >>>>
    >>>
    >>>Is it proof of the same thing when you do it?
    >>>
    >>>You seem to do it alot

    >>
    >>
    >> Where?
    >>

    > Do you have a problem with recall?
    >
    > here, wish list overcoming NIS


    Eh? Where in this thread did I say anything like "Go read the papers."? No
    where.

    > here there everywhere


    I see you have made an accusation you can not back up. If you have any thing
    REAL to back up your personal attacks, please provide examples.

    --



  19. Re: md5 collision

    Pat Farrell wrote:

    > Unruh wrote:
    >> Because sha1 is closely based on MD5 it is no longer trusted.
    >> sha256 is recommended. Despite similar names, the algorithm is very
    >> different as I understand.


    > Based on MD5 in what way? Not in any technical aspect, other
    > than both were designed to be cryptographically strong hashes.


    SHA-1
    (http://csrc.nist.gov/publications/fi...-2-change1.pdf)
    and MD5
    (http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html)
    are structurally so similar that when NIST proposed SHA,
    people wondered why they didn't just use MD5, which MD5
    inventor Ron Rivest offered freely. The main difference
    is that SHA-1 mushes your data through *five* 32-bit
    registers to produce a 160-bit hash, while MD5 mushes
    it through *four* 32-bit registers to produce a 128-bit
    hash. The nature of the mushing, however, is very similar:
    a dataflow diagram of MD5 looks very much like a dataflow
    diagram of SHA.

    SHA256, in contrast, looks quite different.

    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. NIST recently hosted a "What
    Shall We Do About This" workshop
    (http://www.schneier.com/blog/archives/2005/10/),
    at which the consensus seemed to be to pray a lot and use
    SHA256 until somebody figures out how to design better
    hash functions.

    --
    Peter Pearson
    To get my email address, substitute:
    nowhere -> spamcop, invalid -> net


  20. Re: md5 collision

    matt_left_coast wrote:

    > Unruh wrote:
    >
    >>>When dealing with the first case, you create the first of the two files,
    >>>then the file IS known. Then you would be dealing with the second case.

    >>
    >> But you have to create them together. You cannot create one and then make
    >> another which has the same md5.

    >
    > Exact process, please.


    The logic here escapes me. Unruh appears to be claiming that
    you cannot do something ("cannot create one and then make
    another which has the same md5"), and matt_left_coast appears
    to be asserting that Unruh should support that claim by
    detailing how to do something. You cannot show that something
    is impossible by showing how to do something. If
    matt_left_coast wishes to claim that one can find a preimage
    to a given hash, it's up to him to specify how.

    A recent paper on md5 attacks is "Improved Collision Attack on MD5"
    by Yu Sasaki, Yusuke Naito, Noboru Kunihiro, and Kazuo Ohta,
    available at http://eprint.iacr.org/2005/400.pdf. The procedure
    is outlined in section 3.4. While the details are not essential
    to this discussion, the alert reader will note that the attack
    does *not* produce a preimage for a given hash, but rather produces
    a pair of messages whose hashes match. Unruh is quite right.

    --
    Peter Pearson
    To get my email address, substitute:
    nowhere -> spamcop, invalid -> net


+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast