使用 Diffie-Hellman 問題的 AES 加密
這是一直困擾著我的事情，我想知道答案。
DH 過程完成後，AES 是否會創建自己的共享秘密對稱密鑰？
我並不熟悉它，因為我知道說 SSL（RSA，AES）的過程，其中公鑰加密 AES 對稱密鑰，然後將其發送過去，主機 2 用私鑰解密，現在知道共享密鑰。
對於 DH，我總是有相互矛盾的答案，有人說如果你創建一個 1024 位 DH 密鑰，然後 AES 會創建 128 位對稱密鑰並將其傳遞，我不覺得是這種情況（我很高興無論哪種方式都可以更正）。有些人還說來自 DH 的密鑰是 AES 用於加密的密鑰。我的問題是，它不只是使用 1024 位 pub/pri 密鑰交換來加密和解密數據，還是在中間？
謝謝您的幫助
DH 過程完成後，AES 是否會創建自己的共享秘密對稱密鑰？
不可以。AES 使用由 Diffie-Hellman 密鑰協議生成的密鑰，可能是在使用 KDF 或 PRF 派生密鑰之後。
對於 DH，我總是有相互矛盾的答案，有人說如果你創建一個 1024 位 DH 密鑰，然後 AES 會創建 128 位對稱密鑰並將其傳遞，我不覺得是這種情況（我很高興無論哪種方式都可以更正）。有些人還說來自 DH 的密鑰是 AES 用於加密的密鑰。我的問題是，它不只是使用 1024 位公鑰/私鑰交換來加密和解密數據，還是中間的東西？
Diffie-Hellman 是一種非對稱密鑰協商協議。它需要兩個 Diffie-Hellman 密鑰對（使用安全隨機和 Diffie-Hellman 密鑰生成過程生成）。這些密鑰對中的任何一個都可以是臨時的（即使用一次或只使用幾次）或靜態的（持久的，DH 證書的一部分）。交換公鑰後，將執行 Diffie-Hellman 計算並生成共享密鑰- 這是可以從中導出共享 (AES) 密鑰的基值。
共享的秘密很大並且不是完全隨機的。因此，通常它通過密鑰派生函式或 KDF 執行，以從共享密鑰中計算密鑰。TLS/SSL 將此稱為偽隨機函式或 PRF - 一個更通用的術語。對於舊版本（1.0 和 1.1），TLS PRF 在內部使用 MD5 和 SHA1 的組合（在 HMAC 結構中加倍，進一步加倍）；1.2 對預先存在的密碼套件（在數據記錄上為 HMAC 指定 MD5 或 SHA-meaning-SHA1）使用 SHA256（在雙 HMAC 中），但新定義的套件可以為 PRF 命名不同的散列，並且有些確實使用 SHA384，結合 AES-256 進行加密。
除了主密鑰之外，KDF 還使用客戶端/伺服器的身份和標籤來派生密鑰。最後，您應該總共有兩個或四個密鑰：如果使用 GCM 等經過身份驗證的加密，則為兩個，如果身份驗證 (HMAC) 與加密分開執行，則為四個。在 1.0 中，KDF 還為 CBC 套件派生了兩個初始 IV（這與一個缺陷相關，因為已修復），在 1.2 中，KDF 還可以為 GCM 或 CCM 套件派生兩個部分 IV。
其中一個密鑰用於加密和可能驗證從客戶端到伺服器的消息，一個用於另一個方向的消息。AES 是否用於加密取決於密碼套件。
對於 TLS 1.3，需要使用臨時密鑰（DHE 或 ECDHE）。還需要經過身份驗證的加密（AEAD 密碼），因此只需生成兩個密鑰即可用於正常數據加密，儘管 1.3 還派生了在握手期間使用的更多密鑰，並且可以選擇用於特殊目的。如果使用 RSA 或 ECDSA，則僅用於驗證客戶端/伺服器；RSA 或 ECDSA 都不會直接參與密鑰協議。
DH 過程完成後，AES 是否會創建自己的共享秘密對稱密鑰？
不，Diffie-Hellman 建立了 AES 使用的共享密鑰。
對於 DH，我總是有相互矛盾的答案，有人說如果您創建 1024 位 DH 密鑰，那麼 AES 會創建 128 位對稱密鑰並將其傳遞
這是不准確的。
有些人還說來自 DH 的密鑰是 AES 用於加密的密鑰。
這是準確的。
我的問題是，它不只是使用 1024 位 pub/pri 密鑰交換來加密和解密數據，還是在中間？
Diffie-Hellman 是一種密鑰協商算法。它允許兩方通過不安全的通信通道建立共享秘密。公鑰和私鑰可用於生成相互共享的秘密。
AES 是一種分組密碼，需要將秘密材料的來源用作密鑰。它還需要一種操作模式和初始化向量來用作加密多個數據塊的密碼，但這超出了問題的範圍。
結論
Diffie-Hellman 用於建立共享秘密，該秘密通常經過雜湊處理以創建可與對稱密碼（如 AES）一起使用的密鑰。