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

What are you talking about?

System.Security.Cryptography.MD5
System.Security.Cryptography.MD5CryptoServiceProvider

Answer 3

It's been there since the begining

// Create a new instance of the MD5CryptoServiceProvider object.
MD5 md5Hasher = MD5.Create();

// Convert the input string to a byte array and compute the hash.
byte[] data = md5Hasher.ComputeHash(Encoding.Default.GetBytes(input));

// Create a new Stringbuilder to collect the bytes
// and create a string.
StringBuilder sBuilder = new StringBuilder();

// Loop through each byte of the hashed data 
// and format each one as a hexadecimal string.
for (int i = 0; i < data.Length; i++)
{
    sBuilder.Append(data[i].ToString("x2"));
}

// Return the hexadecimal string.
string hexMD5hash = sBuilder.ToString();

Answer 4

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. The CSP algorithms are always going to be faster than their managed counterparts, and I would think the main reason to use MD5 would be to compare files to check for duplicates (such as people uploading duplicate images to an image gallery), which you would want to calculate as quickly as possible, but you also wouldn't need to rely on the utmost security to achieve that.

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

Answer 5

MD5 is not suitable for any cryptographic or file verifying purpose except for possibly error detecting transmission errors. This is probably an effort to get people to move to better hashes like SHA-1 or preferable SHA-256.

http://www.mscs.dal.ca/~selinger/md5collision/

Answer 6

In .NET anything that ends in CryptoServiceProvider wraps the unmanaged Windows Crypto API. Anything that ends in Managed is written entirely in a managed language. link text

As other people stated you shouldn't use MD5 anymore. You should use SHA-256 which in .NET has a Managed implementation. You're good to go and trading up to a better algorithm. (EDIT) As MD5 is no longer kosher, there's little chance of this being updated in a later version of .NET to be entirely managed as you shouldn't be using it anymore anyways.

Answer 7

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.