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

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

MD5CryptoServiceProvider has been in the .NET Framework from day one, actually:

byte[] hash = new MD5CryptoServiceProvider().
    ComputeHash(Encoding.ASCII.GetBytes("Hello World!"));

Note that all .NET BCL classes which encapsulate hashing algorithms inherit from HashAlgorithm class, so these can be used polymorphically ...

public byte[] ComputeHash(byte[] buffer, HashAlgorithm hashAlgorithm)
{ ...

...and different implementations can be Dependency-Injected into your code:

public HashAlgorithm HashAlgorithm { get; set; }

EDIT

Aha, I see. The thing with MD5 (this is pure speculation) is that it's one of the most widely used hashing algorithms, and being such, its implementation is required to conform to certain standards -- more specifically, FIPS 140-1. See this for more info.

Answer 2

Since I didn't design the framework, I can't say for sure, but I believe they probably didn't bother in order to discourage its use for security reasons.

I had originally believed that the unmanaged implementation would be faster, but we now know that is not the case, see: https://stackoverflow.com/a/14850676/58391

My next best guess aligns with what Pavel says in the comments above. As with most features in .NET and C#, there probably just wasn't enough benefit over cost to implement, test, and ship the feature when the underlying unmanaged one was already good enough.

It would be interesting to see a real answer though from someone who designed the language.