|This is the talk page for discussing improvements to the MD5 article.
This is not a forum for general discussion of the article's subject.
|WikiProject Cryptography / Computer science||(Rated C-class, Top-importance)|
|WikiProject Computing / Networking / Software / Websites / CompSci / Security||(Rated C-class, Mid-importance)|
|WikiProject Internet||(Rated C-class, Mid-importance)|
|To-do list for MD5:|
|This talk page is automatically archived by Lowercase sigmabot III. Any threads with no replies in 90 days may be automatically moved. Sections without timestamps are not archived.|
The figure uses the part of the message Mi.
But in the code and the RFC it is Mg with g either i, (5i + 1) mod 16, (3i + 5) mod 16 or (7i) mod 16.
Additionally the rotation of inside the figure should be si an not s only
Comment on content management systems is irrelevant
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)
Pseudocode OK ?
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!)