Why is there no managed MD5 implementation in the

Question

(Re-written question, please see history for original).

The question is right there in the title.

Why is there no managed MD5 implementation in the .NET framework?

I'm specifically talking about a purely managed code implementation of the MD5 algorithm, which does not exist within the .NET framework.

Within the System.Security.Cryptography namespace, I am aware of the MD5 abstract base class (which has to be inherited and can't be used as is), and I'm also aware of MD5CryptoServiceProvider and MD5CNG which both provide implementations from the OS's underlying CSP (Crypto Service Provider) and CNG (Cryptography Next Generation) providers respectively, however, both of these implementations are unmanaged code.

UPDATE ON ANSWERS:
I appreciate that, whilst there should be "one true answer" to this question, we (the SO community) may not know it unless a Microsoft framework designer (or someone who knows one directly) is part of this community, however, many people have offered very reasonable "educated guesses" as to the thinking that went into omitting a managed MD5 implementation from the framework, however, I'm still curious to know if anyone does know the "real" answer to this question.

Answer 1

This is entirely speculation based on reading many posts from various Microsoft bloggers (although not the particular person who made this decision). There is no managed MD5 implementation in the .NET framework because:

1) An implementation was already available from the unmanaged Windows Crypto API and they couldn't afford to, or more likely felt they had better things to do than, devote resources to implementing something that could already be wrapped from an underlying unmanaged implementation. More insight into why they might make this decision can be found by reading How many Microsoft employees does it take to change a lightbulb?, Minus 100 points (applies to the C# compiler but demonstrates the same mindset of spending resources where they do the most good), Why Doesn't C# Implement "Top Level" Methods? (another look at the resources required for a single feature) and features don't exist by default (linked from here). None of these answers the specific question, but they all demonstrate that writing new code requires a lot of resources, resources that may be better spent elsewhere. You can argue that wrapping the underlying unmanaged code still requires resources, but I don't think there is any doubt that there would be net savings by not re-writing code which is already available, tested, and working.

2) Later, or possibly near the same time, research proved the feasibility of collision attacks against MD5. At that point, the already high bar to having MD5 re-written in managed code probably got even higher. Once the Security Development Lifecycle dictated don't use banned crypto I can imagine a managed version of MD5 would be the last thing they would devote resources to.

Although my answer is entirely speculation, it is not difficult to understand that even Microsoft has limited resources and a large list of features they would like to include. Choices have to be made and those decisions will almost always affect a certain segment of developers.

In closing, you said yourself that there are 3rd party MD5Managed classes, or you could always roll your own. A managed version of MD5 might be a "five minute feature", but if it really is, then as programmers we can write it ourselves.