從Diffie-Hellman輸出中選擇一個加密密鑰

我在Java中實現了Diffie–Hellman key exchange，其中有一些大型組RFC 3526。我的輸出是一個相當大的字節數組。 使用河豚鍵的輸出的第一個448位（56字節）安全嗎？我是否應該以任何方式轉換字節，或者爲鍵選取任何特定的字節？從Diffie-Hellman輸出中選擇一個加密密鑰

來源

2010-10-06 Eric Lathrop

從理論的角度來看，不，它不安全。並不是我可以指出實際的攻擊;但是Diffie-Hellman密鑰交換的輸出是由q元素組成的組中的一個元素，並且最多提供sqrt（q）安全性。截斷該元素的編碼部分看起來不是一個好主意...

「正確的」方法是使用單向密鑰導出函數。簡而言之，使用散列函數（如SHA-256）處理Diffie-Hellman輸出，並使用散列結果作爲關鍵字。關於Diffie-Hellman步驟，散列時間可以忽略不計。 Java已經包含了SHA-256和SHA-512的良好實現，並且如果你是在兼容非常古老的Java實現之後（例如隨Internet Explorer 5.5提供的Microsoft JVM），那麼你可以使用獨立的SHA-2 Java實現如sphlib中的一個。或者可能從spec中重新實現（這並不難）：FIPS 180-3 (a PDF file)。

如果你需要超過128位的密鑰，那麼這意味着你是2050年左右的時間旅行者;假設您使用適當的對稱加密方案，128位（遠遠）足以保護您。

說起來：河豚不是真的推薦了。它有64位塊，這意味着當加密的數據長度達到幾千兆字節時會產生麻煩，現在的大小並不那麼大。你最好使用128位塊密碼，如AES。而且，在任何嚴重的對稱加密系統中，您都需要密鑰完整性檢查。這可以通過使用諸如HMAC之類的MAC（消息認證代碼）來完成，其本身構建在散列函數之上（然後再次，易於實現，並且在sphlib中有Java實現）。或者，甚至更好的是，在組合的加密/ MAC模式下使用AES，這將爲您處理棘手的細節（因爲恰當地使用分組密碼是而不是容易）;查找CWC和GCM（兩者均無專利權;後者已獲NIST批准）。

來源

2010-10-06 12:02:22

非常豐富。我正在使用相當小包大小的UDP通信加密。從我讀過的內容來看，Blowfish看起來媲美AES，但速度更快。我以前忽視了MAC，但現在我會仔細研究一下。 – 2010-10-07 00:40:17

對於與速度有關的任何事情，您都應該進行測量。與12年前的3DES相比，河豚被認爲是快速的;但AES比3DES快得多。河豚也被稱爲有一個慢鑰匙計劃（改變一個新的鑰匙是昂貴的）。從安全角度來看，AES要好得多，如果只是因爲它被更多的密碼學家仔細研究。 Blowfish設計師甚至製作了一個名爲Twofish的新版本，該版本是成爲AES的候選人（但是Rijndael被選中，併成爲AES）。 – 2010-10-07 11:51:54

正確的方法是使用標準，而不是自己設計密碼方案。 – Accipitridae 2010-10-13 08:57:55

您提出的解決方案取決於Diffie-Hellman交換的最重要的位是否是硬核。已知有一些小的結果表明最重要的位是不可預測的，但我不知道有足夠強的文件表明您的方法是正確的。

但是，有幾個關於從Diffie-Hellman密鑰派生密鑰的建議。例如一個不錯的論文是NIST SP 800-135。到目前爲止，這只是一個草案，可以找到here。但是，它審查了一些現有的標準。當然，使用標準總是比你自己開發更可取。

儘管Thomas Pornin的建議看起來合理，但它仍然是一個臨時解決方案。爲了安全起見，你應該不要使用它。相反，我會使用已經分析過的東西（例如，TLS版本1.2中使用的密鑰派生方案）。

來源

2010-10-13 08:56:20 Accipitridae

從Diffie-Hellman輸出中選擇一個加密密鑰

回答

相關問題