Talk:MD5/Implementation

The original MD5 page was not enough

After reviewing the original MD5 page and realizing it was all over the map, it seemed reasonable to want to show off native capabilities of languages to meet a well specified and demanding problem. Most of the solutions on the original MD5 page will not satisfy this task description.

• Autohotkey has a largely native implementation that uses a couple of DLL calls. However, the core of the algorithm is implemented as native code and meets the intent here.
• C, Liberty Basic, Matlab (if fixed), Modula3 all seem to satisfy the coding part of the task
• Common Lisp may qualify if more is shown, as may Forth
• The Python examples use hashlib which uses an external call. However, there is Python 2 code http://www.equi4.com/md5/ that is native and a direct translation of RFC 1321 with the RSA copyrights (I think a derivative work of an RFC is fair game but haven't actually checked it out).

Basically, I think this is ready but wanted input/review.

I considered adding a 'performance' measure but was wondering how to compare apples to apples with so many different processors around.

--Dgamey 03:08, 29 September 2010 (UTC)

"Usind native facilities" sounds like "using built-in features" which leads me to believe that if the language has a built-in library for this then that's ok. The examples show the opposite. Maybe change it to "coding the algorithm directly (not using a call to a built-in or external hashing library)" or something like that? The name should probably be changed to "MD5/Implementation" to fit with the link list tasks. --Mwn3d 12:30, 29 September 2010 (UTC)

Changed the wording (clearer is always better). And moved it. --Dgamey 13:11, 29 September 2010 (UTC)

Off-site code

The task (and RC) policy requires code to be on this site. While a link to supplemental code offsite is fine, the code satisfying the task should be on this site. --Dgamey 01:46, 30 September 2010 (UTC)

Ok, I have grabbed the code and pasted a copy here. However,

1. I would like a link to this rosetta code policy. The only policy page I can find is the (very brief) privacy policy page. If we have policies here I want to know them!
2. The task requirements did not require the code be present here (and, arguably still do not). The task said that code present here would be accepted but I understood that to be an inclusive statement rather than an exclusive statement. When I am fixing a draft to conform with the task specification, I feel more comfortable when the task I am implementing is explicitly stated rather than implicit but not stated (I expect that this might save other people time, later).
3. RFC 1321 includes a license which requires some specific statements when this algorithm is implemented, and a number of the implementations here do not include those statements.

Thanks!

--Rdm 16:39, 30 September 2010 (UTC)

Pseudo Code is not enough

Because hash functions are designed to thoroughly mix their inputs, even a small error will result in a completely different hash. A single bit change should result in half the bits of the digest changing. So if you encounter errors in your implementation you will likely need to break down constants, each step, sub-function, and round to find the error.

(from MD5 Talk) Just attempting to code this from the pseudo-code is likely to result in a number of errors. The reference code in the RFC is clearer. --Dgamey 01:38, 30 September 2010 (UTC)