.NET框架中爲什麼沒有託管的MD5實現？

Question

（重寫問題，請查看原始歷史記錄）。

的問題是正確的，在標題。

爲什麼會出現在.NET框架沒有管理MD5實現？

我正在專門討論一個純粹的託管代碼 MD5算法的實現，它在.NET框架中不存在。

內System.Security.Cryptography命名空間，我知道了MD5抽象基類（其中有被繼承，不能直接使用），我的也知道MD5CryptoServiceProvider和MD5CNG其中兩個提供來自OS的基礎CSP（加密服務提供商）和CNG（下一代加密）供應商的實現分別，但是，這兩種實現都非託管代碼。

UPDATE ON解答：
我欣喜的是，雖然有應該「一個真正的答案」這個問題，我們（SO社區）可能不知道它，除非微軟框架設計者（或誰直接知道的），然而，很多人都提供了非常合理的「猜測」這個社會的一部分，到走進省略從框架管理的MD5實現思想，但是，我還是想知道，如果有人不知道這個問題的「真實」答案。

Answer 1

因爲我沒有設計的框架，我不能肯定地說，但我相信他們可能沒有麻煩爲了阻止其出於安全原因而被使用。

我原本認爲，非託管的執行速度會更快，但我們現在知道，情況並非如此，請參閱：https://stackoverflow.com/a/14850676/58391

我的下一個最好的猜測對齊什麼帕維爾說，在上述意見。與.NET和C＃中的大多數功能一樣，如果底層的非託管應用已經足夠好，那麼實施，測試和發佈功能的成本可能不足以超過成本。

雖然從設計語言的人那裏看到真實的答案會很有趣。

Answer 2

MD5CryptoServiceProvider一直在.NET Framework從一開始，實際上是：

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

注意哪些封裝散列算法所有的.NET BCL類從HashAlgorithm類繼承，所以這些可以使用多態...

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

...和不同的實現可以依賴注入到你的代碼：

public HashAlgorithm HashAlgorithm { get; set; } 

編輯

啊哈，我明白了。與MD5的事情（這是純粹的猜測）是，它是最廣泛使用的散列算法之一，被這樣的，要求其實施符合一定的標準 - 更具體地說，FIPS 140-1。有關更多信息，請參閱this。

Answer 3

你在說什麼？

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

Answer 4

它一直在那裏，因爲開始時

// 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 5

MD5不適用於任何加密或文件驗證目的，除了可能的錯誤檢測傳輸錯誤。這可能是爲了讓人們轉向更好的哈希，比如SHA-1或更好的SHA-256。

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

Answer 6

在在CryptoServiceProvider結束.NET任何包裝的非託管的Windows加密API。以Managed結尾的任何內容都完全以託管語言編寫。 link text

正如其他人聲稱你不應該再使用MD5。你應該使用.NET中有一個Managed實現的SHA-256。你很樂意去做一個更好的算法。 （編輯）由於MD5不再是猶太教，在.NET的更高版本中更新的機會很小，完全可以管理，因爲你不應該再使用它了。

Answer 7

這完全是基於閱讀來自各個微博客的許多帖子（儘管不是做出這個決定的特定人員）的推測。在.NET框架中沒有託管的MD5實現，因爲：

1）一個實現已經可以從非託管的Windows Crypto API中獲得，他們無法承受或者更可能感覺他們有更好的事情要做，投入資源來實現可能已經從底層的非託管實現中打包的東西。通過閱讀How many Microsoft employees does it take to change a lightbulb?,Minus 100 points（適用於C＃編譯器，但展示了他們花費最多資源的資源的相同心態），Why Doesn't C# Implement "Top Level" Methods?（另一個查看單個所需資源的更多信息）功能）和features don't exist by default（從here鏈接）。這些都沒有回答具體問題，但他們都表明編寫新代碼需要大量的資源，這些資源可能更適合在其他地方使用。你可以爭辯說，包裝底層的非託管代碼仍然需要資源，但我認爲沒有任何懷疑，因爲不重寫已經可用，已測試和正在工作的代碼，將節省淨資源。

2）稍後或可能接近同一時間，research proved the feasibility of collision attacks against MD5。那時候，以託管代碼重新編寫MD5的標準可能會更高。一旦安全開發生命週期規定don't use banned crypto，我可以想象一個管理的MD5版本將是他們投入資源的最後一件事情。

雖然我的回答完全是猜測，但不難理解，即使是微軟的資源有限，他們希望包含的大量功能也不例外。必須做出選擇，這些決定幾乎總是會影響到某個開發者羣體。

最後，你說自己有第三方的MD5Managed類，或者你總是可以roll your own。管理版本的MD5可能是「five minute feature」，但如果它真的是，那麼作爲程序員，我們可以自己編寫它。