消息摘要強度：級聯vs迭代

Question

如果我有3個字段暴露「明確」，並且我想對這些字段進行數字簽名以確保它們沒有被篡改使用安全的散列函數。我有2種選擇：

1. 我可以連接的3個字段，並使用摘要散列整個事情作爲單個字符串，即散列（FIELD1 + FIELD2 +字段3 +鹽）
2. 我可以迭代散列各個結果，即，散列（FIELD1 +散列（FIELD2 +散列（場3 +鹽）））

顯然接近1將比方法2快，但將接近2在以下方面是任何「更強」的通過對來自各種輸出的輸入進行逆向工程來防止人們發現鹽的價值（我相信是這樣，但它是否值得額外的CPU成本）？

Answer 1

首先，我必須發出標準註釋散列未簽署。數字簽名是涉及密鑰和驗證者的過程。在這裏，您只是想散列一些數據並將散列值保存在一個「安全」的位置，這樣就可以將散列值的完整性擴展到散列數據：確保散列值不被篡改，並且通過在數據元素上重新計算散列並找到相同的散列值，您可以確信字段元素不會被篡改。

然後我必須發出第二個標準評論，那就是沒有性能問題，直到在現實條件下適當測量。散列速度很快。即使是一個不太快的散列函數，一臺基本的PC也將能夠每秒執行數百萬次散列操作。

現在，我看到你想要使用「鹽」。鹽是一段公共數據，其目的是爲了每個實例不同，以防止解密成本分攤。這在有一些加密數據的設置中是有意義的;就我所見，從你所描述的內容來看，你的問題沒有任何加密。

......除非您確實表示您將保留您的「鹽」祕密，並將散列值與數據字段一起存儲。在這種情況下，我們不再討論哈希了。你的「鹽」會被更合適地稱爲「關鍵」，因爲它意味着保密。你不想要一個散列，但一個MAC。有時，MAC被稱爲「簽名」。這不合適，但比調用哈希「簽名」更不合適。如果你想要的是一個MAC（你的鹽真的是一個關鍵），那麼你應該使用你的建設。建立一個MAC不是一件容易的事情：當涉及到安全性時，許多手工製造的建築都會失敗。幸運的是，有一個稱爲HMAC的標準MAC。 HMAC以智能的方式使用底層哈希函數（使用SHA-256）和密鑰，將它們變成MAC。 HMAC受許多加密庫支持。

Answer 2

使用HMAC（基於散列的消息認證碼），而不是試圖組建自己的。它會更安全，幾乎任何平臺都有免費的實現，您可以使用其他人進行開發，測試和維護。

誰能說它「是否值得額外的CPU成本」？你多久會這樣做？你真的需要購買更多的CPU嗎？你付多少電費？在天平的另一面，如果有人成功地篡改受家庭釀造算法「保護」的數據，將花費多少錢？