Talk:MD5

Figure wrong

The figure uses the part of the message M_i.

But in the code and the RFC it is M_g 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 s_i an not s only

I cannot correct the wrong Mi in figure but maybe someone else can.--158.64.4.213 (talk) 10:10, 15 March 2019 (UTC)

Comment on content management systems is irrelevant

The section on MD5 security notes "As of 2019, one quarter of widely used content management systems were reported to still use MD5 for password hashing."

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[0] = ' '<<24 + 'e'<<16 + 'h'<<8 + 'T', M[1] = '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)