我有興趣優化一些大文件的哈希（優化掛鐘時間）。 I/O已經足夠優化，I/O設備（本地SSD）僅佔用容量的25％左右，而其中一個CPU內核已經完全刷新。什麼哈希算法是可並行化的？利用多核CPU優化大文件的哈希
我有更多的內核可用，未來可能會有更多內核。到目前爲止，如果我碰巧需要同一個文件的多個哈希值，那麼我只能使用更多的內核，例如MD5和SHA256。我可以使用相同的I/O流來提供兩個或多個哈希算法，並且我可以免費完成更快的算法（只要掛鐘時間）。就我所瞭解的大多數散列算法而言，每個新位都會改變整個結果，並且它本身具有挑戰性/不可能並行執行。
任何主流哈希算法可並行？
是否有任何可並行化的非主流哈希（並且至少有可用的樣本實現）？
由於未來的CPU將趨向於更多的核心和時鐘速度的平衡，有沒有什麼辦法來提高文件哈希性能？ （除了液氮冷卻超頻？）還是本質上不可並行？
在這方面實際上有很多研究正在進行。美國國家標準與技術研究院目前正在舉行設計下一代政府級散列函數的競賽。大多數提案是可並行的。
一個例子：http://www.schneier.com/skein1.2.pdf
的較量現狀維基百科的描述：http://en.wikipedia.org/wiki/SHA-3
感謝您的鏈接，Skein看起來很有趣，至少有六種語言的實現。只有通過使用標準化的樹分解算法，才能像其他線性哈希函數一樣進行並行化。基本上散列源節點，將散列散列在一起（如果需要，再次分段）等，但是樹形參數然後成爲散列參數的一部分，並且驗證需要再次使用完全相同的參數。我想這會對我有用......但如果有「標準」這將是很好的 – DanO 2010-04-27 04:00:51
你有什麼樣的SSD？我的C實現MD5在單核英特爾Core2核心（2.4 GHz，不是最新的英特爾）上運行速度爲400 MB/s。你真的擁有支持1.6 GB/s帶寬的SSD嗎？我想要一樣！
樹散列可應用於任何散列函數。有一些微妙之處，Skein規範試圖處理它們，在函數本身中集成了一些元數據（這並不會改變很多性能），但Skein的「樹形模式」並不是提交給的「Skein」 SHA-3。即使將Skein選作SHA-3，樹型散列的輸出也不會與「普通Skein」的輸出相同。
希望在某個時候定義一個標準來描述通用樹哈希。現在沒有。但是，已經定義了一些協議，支持使用名爲「TTH」（Tiger Tree Hash）或「THEX」（樹形哈希交換格式）的Tiger哈希函數進行自定義樹哈希。 TTH的規範似乎有點難以捉摸;我發現一些參考文獻已經移動或消失了。
不過，我對這個概念有些懷疑。它是一種整潔，但是隻有在你能夠比單核能夠處理的速度更快地讀取數據時才能提供性能提升，並且，如果正確的功能和正確的實現，單核可以每秒處理大量數據。散佈在多個內核上的樹散列需要將數據發送到適當的內核，並且1.6 GB/s不是有史以來的最小帶寬。
SHA-256和SHA-512不是很快。在SHA-3候選者中，假設採用64位模式的x86處理器，其中一些實現了高速（2.4 GHz Intel Core2 Q6600超過300 MB/s，帶有單核 - 這是我可以得出的結果也是SHA-1），例如寶馬，SHABAL或Skein。從密碼的角度來說，這些設計有點太新了，但MD5和SHA-1已經以密碼方式「破碎」（對於MD5而言非常有效，理論上對於SHA-1來說），因此任何第二輪SHA-3候選應該沒事。
當我把我的「先知」上限，我預見到處理器將繼續變得比RAM更快，以至於散列成本將被內存帶寬所淘汰：CPU將等待時鐘週期以備用來自主RAM的數據。在某種程度上，整個線程模型（對於許多內核來說是一個大內存）將不得不進行修改。
這是部分題外話;實際上，當我要求優化建議時，我總是很討厭*總是有人建議不要打擾，但要購買更好的硬件 2）嘗試證明優化在這種情況下毫無價值 OP證明/試圖證明他需要它，所以我認爲你的意見沒有幫助[「你真的擁有支持1.6 GB/s帶寬的SSD嗎？我想要相同！」]。 所以不能給+1。 – kgadek 2012-02-16 21:13:45
你沒有說你需要你的散列。 如果您不想與外部世界交換內容，只是爲了內部使用，只需將每個文件分成大塊，計算並存儲所有校驗和。然後你可以使用多個核心，只需向每個核心投擲一塊。
想到的兩個解決方案是將文件分成固定大小的塊（更簡單，但對於不需要所有這些功能的較小文件將使用較少的內核）或固定數量的塊將使用每個文件的所有內核）。真的取決於你想達到什麼以及你的文件大小分佈是什麼樣的。
另一方面，如果你需要外部世界的散列，就像你可以從其他回覆中讀到的那樣，對於「標準」散列是不可能的（例如，如果你想發送SHA1散列給其他人檢查用不同的工具），所以你必須找別的地方。就像在存儲文件時計算哈希值，以便以後檢索一樣，或者使用「空閒」核心在後臺計算哈希值並存儲以供以後檢索。
更好的解決方案取決於您的約束條件以及您可以在哪裏投資空間，時間或CPU功率。
此外，我聽說大多數當前散列算法_can_可以並行化，但我不確定需要什麼。顯然，做到這一點的一種方法是自己決定散列每個文件，例如4k塊文件，然後以某種方式組合散列。 XOR，也許？總是危險的加密創造自己的算法，所以我不會相信這一點，如果你是防範惡意數據篡改，而不是意外的數據損壞。 – sblom 2010-04-27 01:51:06
我讀了你鏈接的Skein規範。你在這裏建議的是它如何實現並行化（顯然它被稱爲「樹哈希」）。斯金有一個標準的方式來指定葉大小，扇出和最大樹高，以便任何使用相同參數的人都會得到相同的散列結果。 （這很重要）我想防禦惡意篡改以及意外腐敗。我希望標準已經準備好了。 – DanO 2010-04-27 02:19:16
http://tools.ietf.org/html/rfc1321看起來MD5不容易並行化，每個塊的計算取決於使用所有早期塊計算出來的狀態。如果這個屬性不成立，那麼MD5就不會安全（交換塊的位置不會影響散列 - 這不好）。無論如何，我不認爲MD5的並行化是不可能的，只是一見鍾情。 – kgadek 2012-02-16 21:07:39