Talk:MD5

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)

I followed your comment up until this part

> 0 ... 0, 81, 1, 0, 0, 0, 0, 0, 0]

How did the 88, 1 become a 81, 1? 94.196.94.19 (talk) 22:19, 9 October 2022 (UTC)

d41d8cd98f00b204e9800998ecf8427e 112.197.120.140 (talk) 18:44, 5 September 2023 (UTC)

Ok 2402:9D80:22E:5559:2819:687A:A144:B7CD (talk) 21:11, 19 November 2023 (UTC)

Weakness of MD5 demonstrated once again in a spectacular manner.

Hackers behind the highly stealthy, native Apple iOS malware "Triangulation" used forty MD5 hashes to identify various "p0wned" mailboxes held by them, but security researchers managed to crack most of the checksums and retrieved 36 full e-mail addresses, as seen here: https://securelist.com/triangulation-validators-modules/110847/ 77.234.84.8 (talk) 13:13, 25 October 2023 (UTC)

Need to more prominently address vulnerabilities

I strongly feel that the first sentence of this article needs to call attention to the fundamental insecurity of MD5 as a cryptographic hash function. It's literally the first thing that anyone needs to know about it. Some people are not aware of this and continue, even to this day, to use MD5 as a cryptographic hash function despite its unsuitability for this purpose.

I made such an edit on 26 Aug 2023 but it was reverted, the editor making the reversion said simply "Npov". Is there anything non neutral about the edit I made? Everything I said is absolutely accurate according to verifiable sources already cited in the article. Indeed everything I said in my edit the article already said; all I did was move that accurate and verifiable information into the lead sentence.

Another user again added mention of the algorithm's insecurity on 16 Mar 2024, but it was again reverted. This time the reverting editor stated "There's nothing insecure about a hash function, it does what's it supposed to do; the way we used it". This is a bizarre statement, "There's nothing insecure about a hash function"; there certainly is something (very) insecure about this hash function, and it absolutely does not do what it was supposed to do, and presumed to do, when it was designed and first widely implemented. Again, as all already discussed in detail in the article: "Historically it was widely used as a cryptographic hash function; however it has been found to suffer from extensive vulnerabilities. It remains suitable for other non-cryptographic purposes". Uh... right. So is there something wrong with saying it in the lead sentence? "The way we used it" is also a bizarre phrase: the way who used it?

What I, and the other editor, were trying to do, was merely give more prominence to information already discussed. I don't want to start an edit war, so I'm writing here.

Can anyone provide a justification for not stating the single most important fact about the topic of the article in the first sentence of the article?

If no one provides a real objection based in Wikipedia's policies and the facts about the article's topic as confirmed by verifiable sources, I'm going to again edit the first sentence to make clear what the article already accurately states lower down, that MD5 suffers from extensive vulnerabilities and is not suitable for cryptographic purposes.

75.166.157.156 (talk) 01:29, 31 May 2024 (UTC)