This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
However, this is irreverent, because the security of password hashes are not impacted by collisions, they are impacted by the speed of hashing. MD5 is a very fast hash, so it's no longer appropriate for password hashing. I propose moving this to another section, and will probably do so within a few days unless I hear otherwise. Simsong (talk) 01:40, 11 September 2020 (UTC)[reply]
I tried to implement the pseudocode but I couldn't reproduce the results. (EDITED) Now I succeeded and share what might be ambiguous:
append "1" bit to messsage means that you actually append a byte 128 if the message was/is cut into bytes.
append the original length in bits mod 2^64: It means that the last (512 - 448) bit or 64 - 56 = 8 byte of the padded message are filled with that number, ((number of bytes in original text) MOD 2^61) * 8, padded to length of 8 byte, little endian. E.g., for "The quick (...) lazy dog" (length = 43 byte = 344 bit), this would be (88, 1, 0, 0, 0, 0, 0, 0) for 1*256 + 88 = 344. Thus, the padded message would be, written in bytes: [84 (='T'), 104(='h'), 101(='e'), ..., 100(='d'), 111, (='o'), 103(='g'), 128, 0 ... 0, 81, 1, 0, 0, 0, 0, 0, 0].
Ignore the instruction "Be wary of the below definition...". I assume it means "take into account", but how could we anyway anticipate at that point assignments that occur at a later moment?! Just ignore.
The "digest": a0 append ... append d0 // (output is in little endian): If, in the end, a0 = 1, b0 = 2, c0 = 3, d0 = 4, the output should be "01000000020000000300000004000000"!
Most of it all, the 16 32-bit words M[j] correspond each to 4 consecutive bytes of the message scrambled by reading the chunk in little endian! So for the above phrase, M = ' '<<24 + 'e'<<16 + 'h'<<8 + 'T', M = 'c'<<24 + 'i'<<16 + 'u'<<8 + 'q', etc. (Mnemonic: little endian is the most counter-intuitive and inconsistent convention you could think of. To make it worse, it is the opposite of what its name suggests! The 'litte' bit (LSB) is not at the end (as in "endian"), but at the beginning - speaking of the least significant byte. The least and most significant bits aren't on either side, but somewhere inside! Congrats on your choice, guys!)
Thanks if others can confirm any part of this interpretation. — MFH:Talk 19:09, 2 October 2020 (UTC)[reply]