Aes
安全通信
重點：
我必須設計一個安全的保持活動通信協議，並且想知道是否有必要在生成會話密鑰後對密文進行簽名，因為攻擊者不知道密鑰。
協議概述：
- 客戶端和伺服器都有各自公鑰的副本。
- 使用 ECDH 生成會話密鑰。參數將被簽名並發送給雙方。
- 在 GCM 模式下使用 AES 加密的進一步通信。IV和Tag附加到密文後發送給對方。
旁注：
如何引入前向保密？
我……想知道是否有必要簽署密文
不，不需要對密文進行簽名。密鑰已經由密鑰協商協議派生，這是安全的，因為您驗證了參數（我認為其中包括每一方的臨時公鑰）。
此時，您只需驗證每一方確實具有相同的共享密鑰。一種方法是驗證 GCM 加密消息。
問題在於：
- 您需要發送一條消息（在您同意密鑰後可能需要一些時間）和
- 您現在正在混合實體身份驗證和消息身份驗證。
第 2 部分對開發人員和維護人員來說是一個主要的痛苦，因為他們將不得不混合概念。例如，如果第一條消息失敗，您將記錄什麼？是經過身份驗證的消息（通常更大）的數據損壞，還是一開始就建立會話失敗？
因此，一旦建立共享密鑰，您最好將特定於實體身份驗證的 MAC 發送給另一方，最好使用不同的派生身份驗證密鑰。您可以使用 KDF 例如為此目的建立身份驗證密鑰和消息加密密鑰。
第一個 MAC 可以與最後交換的臨時公鑰一起發送；此時一方已經擁有另一方的公鑰，畢竟可以建立共享秘密。不幸的是，如果對方需要快速進行身份驗證，可能會花費您額外的消息。當然也有解決方案，但是是的……
如何引入前向保密？
如果您為雙方使用臨時 (EC)DH 密鑰對來建立會話密鑰，那麼您已經獲得了前向保密。當然，這假設您在建立會話密鑰後儘快銷毀臨時私鑰。
請注意，會話不能免於攻擊，例如將來由量子電腦找到私鑰。前向保密不是萬能藥（這就是為什麼我通常堅持使用“前向保密”而不是“完美前向保密”，即使“完美”部分與破壞密鑰協商算法無關）。