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

Question

我在Java中使用RFC 3526中的一些大型組實現了Diffie-Hellman密鑰交換 。 我的輸出是一個相當大的字節數組。 使用河豚鍵的輸出的前448位（56字節）是否安全？ 我應該以任何方式轉換字節，還是選擇密鑰的任何特定字節？

Answer 1

從理論的角度來看，不，這不安全。 不是說我能指出實際的攻擊; 但是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中的那個 。 或者可能從規范中重新實現它（這並不難）： FIPS 180-3（PDF文件） 。

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

說到這個：不再推薦Blowfish了。 它有64位塊，這意味着當加密數據長度達到幾千兆字節時會遇到麻煩，這個大小現在還不是很大。 您最好使用128位分組密碼，例如AES 。 此外，在任何嚴肅的對稱加密系統中，您都需要進行密鑰完整性檢查。 這可以通過MAC（消息認證代碼）來完成，例如HMAC ，它本身是通過散列函數構建的（然后再次，易於實現，並且sphlib中有Java實現）。 或者，更好的是，在組合加密/ MAC模式下使用AES，它將為您處理棘手的細節（因為正確使用分組密碼並不容易）; 查找CWC和GCM （均為無專利;后者已獲得NIST批准）。

Answer 2

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

但是，有一些關於Diffie-Hellman密鑰的密鑰推導的提議。 例如，一篇好文章是NIST SP 800-135。 到目前為止，這只是一個草案，可以在這里找到。 但是，它審查了一些現有標准。 當然，使用標准總是比自己開發更好。

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