如果密鑰用於解密已簽名的消息，是否需要對其進行簽名？
我試圖更好地理解身份驗證。假設我在某個論壇上發布了我的 128 位 AES 對稱密鑰，使用 256 位 ECC (25519) 對我的朋友進行了非對稱加密。該論壇不受我們控制，因此此關鍵資訊可能會被篡改。
然後，我在論壇上發布了一堆使用該 AES 密鑰加密的實際通信消息，並使用 ECC 25519 簽名密鑰對它們進行簽名，我的朋友可以安全地使用它來驗證消息沒有被篡改。
我是否還需要對我的 AES 密鑰消息進行簽名，或者是否對密鑰正確解密我的簽名消息進行了充分的身份驗證檢查？如果密鑰被篡改，它將無法將我的消息解密為有意義的內容？
我試圖更好地理解身份驗證。假設我在某個論壇上發布了我的 128 位 AES 對稱密鑰，使用 256 位 ECC (25519) 對我的朋友進行了非對稱加密。該論壇不受我們控制，因此此關鍵資訊可能會被篡改。
首先，請注意，使用curve25519 加密並不像使用RSA 加密那麼簡單，您可能必須使用ECIES或類似的東西。您通常會看到（並使用）ECC 用於數字簽名和密鑰交換，只是為了讓您知道。
然後，我在論壇上發布了一堆使用該 AES 密鑰加密的實際通信消息，並使用 ECC 25519 簽名密鑰對它們進行簽名，我的朋友可以安全地使用它來驗證消息沒有被篡改。
我是否還需要對我的 AES 密鑰消息進行簽名，或者是否對密鑰正確解密我的簽名消息進行了充分的身份驗證檢查？如果密鑰被篡改，它將無法將我的消息解密為有意義的內容？
讓我們考慮一下如果您不簽署 AES 密鑰會發生什麼。最壞的情況是，惡意論壇管理員會修改您的消息並將您的 AES 密鑰替換為他們自己的密鑰（使用您朋友的公鑰加密）。如果他們成功並使用他們自己的密鑰向您的朋友發送消息，則可能會發生以下三種情況之一：
- 您的朋友解密消息，看到例如一些有效的英文文本並說 OK，這條消息看起來不錯，密鑰一定沒問題。
- 您的朋友不會解密郵件，因為郵件上沒有簽名。
- 如果攻擊者確實使用他們自己的密鑰對消息進行了簽名（因為他們無法偽造您的簽名），那麼您的朋友會嘗試使用您的公鑰驗證簽名，這將失敗（此時您的朋友應該丟棄密文）。
在三分之二的情況下，攻擊將失敗，但如果您的朋友願意在不檢查其完整性的情況下解密密文（也稱為密碼末日原則），那麼攻擊就有可能成功。所以這取決於你的朋友做什麼。
在這種情況下，我建議使用稍微不同的結構。假設您有私鑰/公鑰對 $ (sk_A, pk_A) $ 你的朋友是 $ (sk_B, pk_B) $ , 符號 $ function_{key} $ 意味著執行 $ function $ 使用鑰匙 $ key $ 和 $ || $ 表示串聯：
- 生成兩個密鑰，一個用於 AES ( $ k1 $ ) 和一個用於 MAC 例如 HMAC ( $ k2 $ )
- 簽署您生成的密鑰（ $ sig = \text{Sign}{sk_A}(k1 \text{ || } k2) $ ) 並將加密的簽名和密鑰發送給您的朋友： $ \text{Encrypt}{pk_B}(k1 \text{ || } k2 \text{ || } sig) $ .
- 您的朋友應該解密，驗證簽名，然後獲取密鑰。
- 發送消息 $ m $ 給你的朋友加密它以產生 $ c = \text{AES}{k1}(m) $ 然後發送消息 $ (c \text{ || } \text{HMAC}{k2}(c)) $ . 這是“Encrypt-Then-Mac”結構，您可以在此處了解更多關於其安全性的資訊。
- 你的朋友應該在收到消息後驗證 MAC，如果沒問題，然後解密密文。
請注意，您的消息的真實性是從 MAC 確定的，而 MAC 又是由您使用私鑰簽署密鑰這一事實確定的（ $ k2 $ ) 在計算 MAC 時使用。