使用 RSA 進行安全加密後簽名
我了解，當您想使用 RSA 加密和簽名數據時，通常推薦的方法是先簽名後加密。
但是，我已經加密了需要簽名的數據，以證明加密數據的作者。
- 使用收件人的公鑰加密
- 使用作者的私鑰簽名
- 將密文與簽名連接起來
從閱讀諸如此類的論文來看，簽名然後加密的問題似乎非常微妙，但解決方案非常簡單。
我無法在加密然後簽名的問題上出現很多問題。我想一個問題是有人可以簡單地剝離簽名並用他們自己的替換它。我的第一個想法是在加密之前用作者的公鑰為數據添加前綴，但是簽名只能“真正”由接收者驗證（公開驗證對我來說更可取）。
與加密然後簽名相關的問題是什麼，存在哪些解決方案？
編輯
對於有人用自己的簽名替換原始簽名的問題，我想到了另一種可能的解決方案——使用 X.509 證書。所以在上面的第 3 步中，我們還連接了作者的證書。在驗證簽名時，我們檢查公鑰是否與證書匹配，並且我們還驗證證書是否由特定的受信任 CA 頒發。使用這種方案，不僅任何人都可以替換簽名，只有那些從受信任的 CA 頒發證書的人才能替換簽名。這種方法有什麼問題嗎？
加密然後簽名（對密文進行簽名）的主要問題涉及為了分配責任而簽名與為了獲得信用而簽名之間的區別。Encrypt-then-sign 對前者來說是可以的，但對後者來說不是。這個問題相當微妙。
特別是，在您的協議中，接收者沒有理由相信發送者（簽名者）曾經知道明文的內容。簽名者必須知道密文的內容並同意對密文進行簽名，但這並不意味著簽名者知道或創建了原始消息。
例如，假設我們使用它來登錄一個站點。假設作為系統管理員的 Alice 將向作為伺服器的 Sam 進行身份驗證。假設為了進行身份驗證，Alice 將使用您的方案將根密碼的副本發送給 Sam（加密然後簽名）；如果一切順利，Sam 將斷定 Alice 知道 root 密碼，並且應該被授予對伺服器的完全訪問權限。聽起來很合理，對吧？但現在看看會出現什麼問題。Mallet 可以攔截 Alice 的加密然後簽名的數據包，剝離 Alice 的簽名，附加她自己的簽名，然後轉發給 Sam。Sam 將收到它，一切都會檢查出來：Sam 可以看到這是由 Mallet 簽名並解密以包含正確的 root 密碼，因此 Sam 將得出結論，應該授予 Mallet 對伺服器的完全訪問權限。
後一個範例中可能發生攻擊的原因是 Alice 和 Sam 使用簽名作為獲得信任的基礎：Alice 試圖將知道 root 密碼的知識作為信任，而 Sam 願意接受簽名作為證據為了那個原因。但是，加密然後簽名不提供允許發件人將消息內容的知識歸功於自己的基礎。
因此，此方案是否足夠取決於您擁有的特定應用程序。許多應用程序只需要為了分配責任而進行身份驗證：如果出現問題，我們知道該由誰負責（或者，我們知道要對誰的帳戶收費或減少誰的配額），然後加密就可以了。但是一些應用程序（我提到的密碼驗證範例；拍賣；以及其他一些應用程序）使用驗證來額外允許各方因對消息的了解而獲得信任。對於這些應用程序，vanilla encrypt-then-sign 可能會出現問題。
有一些方法可以修復 encrypt-then-sign，因此它沒有這個缺點。有關詳細資訊，請參閱下面的研究文獻。
有關所有這些的更多詳細資訊，包括可能出現的問題以及如何避免這些問題，您可以閱讀研究文獻中的以下詳細說明：
- 加密協議的審慎工程實踐。馬丁·阿巴迪和羅傑·李約瑟。請參閱第 5.2 節（但整篇論文都很棒而且很經典）。
- 安全協議及其屬性。馬丁·阿巴迪。見第 5 節。
實際上，Encrypt-then-MAC (EtM) 被認為是實現認證加密 (AE) 的最安全機制。
Mihir Bellare 還有一篇關於這個主題的研究論文： https ://cseweb.ucsd.edu/~mihir/papers/oem.pdf
這是 Dan Boneh 的加密課程的另一個資源，其中討論了完全相同的事情（幻燈片 29）。 https://crypto.stanford.edu/~dabo/courses/OnlineCrypto/slides/07-authenc-v2-annotated.pptx
此外，關於使用 EtM 範例的另一個連結： https ://moxie.org/blog/the-cryptographic-doom-principle/