通過 TLS 1.3 發送的加密電子郵件是否是一種“前向保密”形式（類似於 Signal）？
關於 GPG 加密電子郵件的一個常見抱怨是它不提供前向保密。然而，隨著機會性 TLS在 IMAP 和 SMTP 中變得越來越普遍，期望從一個郵件傳輸代理 (MTA) 發送到另一個郵件傳輸代理 (MTA) 的電子郵件是通過利用 (EC)DHE 的 TLS 協議完成的並非沒有道理 - 迄今為止最大電子郵件提供商Gmail預設配置為以這種方式發送和接收電子郵件。因此，如果郵件使用者代理 (MUA) 和消息送出代理、MUA 和消息傳遞代理以及 MTA 和 MTA 之間的通信是使用這樣的協議（例如，TLS 1.3）完成的；那麼即使用於加密電子郵件的 GPG 密鑰是相當靜態的，這不應該構成“前向保密”嗎？
在我看來，解密別人的電子郵件的唯一方法是端點設備已被入侵。不過，這對於 Signal 也是如此。我弄錯了嗎？
前向保密是一個令人困惑的術語，應該放棄，**尤其是無意義但具有價值的變體“完美前向保密”。它尤其令人困惑，因為它通常與執行臨時 DH 密鑰協議的任何協議相關聯，例如 TLS——即使在 TLS<1.3 會話恢復中，能夠解密過去會話記錄的密鑰被故意保留很長時間時間。 相反，您應該問：誰擁有數據，誰擁有解密密鑰，何時可以擦除解密密鑰？
假設 Alice 決定要向 Bob 發送一條消息，並將其輸入到她的筆記型電腦中。
讓我們看看電子郵件中的數據流。
- Alice 的筆記型電腦通過 Internet 將消息加密發送到 Alice 的 MTA outbound.oohay.com。
- Alice 的筆記型電腦和 Alice 的 MTA 的傳出.oohay.com 之間的解密密鑰可以在此步驟之後被刪除，但現在傳出.oohay.com必須具有消息的明文副本。
- 傳出.oohay.com 通過網際網路將消息發送到鮑勃的 MTA 傳入.oogleborg.com，並進行加密。
- 在這一步之後，outcoming.oohay.com 和incoming.oogleborg.com 之間的解密密鑰可以被刪除，但是現在incoming.oogleborg.com必須有一個明文副本。
- 幾天后，Bob 度假回來後，他登錄到他的工作站並通過網際網路從incoming.oogleborg.com 下載加密的消息。
- Bob 的工作站和incoming.oogleborg.com 之間的解密密鑰可以在此步驟之後被擦除，但是擦除*TLS 會話的密鑰對Oohay 和Oogleborg 的伺服器上留下*的明文副本沒有幫助！**
如果 Alice 的消息是 OpenPGP 加密的消息，那麼您還需要回答： Bob 什麼時候擦除他的解密密鑰的所有副本？如果不是在 Bob 的筆記型電腦被入侵之前，那麼即使 Bob 刪除了舊電子郵件，攻擊者也可以使用 Bob 的解密密鑰來解密舊電子郵件的密文。
相比之下，這是 Signal 中的流程。
- Alice 的筆記型電腦使用她目前為 Bob 提供的密鑰對消息和一些棘輪式管理進行加密，並將其發送到 Google 母艦進行分發。
- Google母艦必然有消息的密文副本，並且不需要密鑰。
- Alice 現在可以轉動她的棘輪並擦除允許解密儲存在 Google 母艦上的密文的密鑰。
- 此後，如果 Alice 遵循了協議，則只有 Bob擁有解密密文或任何派生方式的密鑰。
- 幾天后，Bob 度假回來後，他登錄到他的工作站並從 Google 母艦
下載密文。
- 如果棘輪管理員顯示消息是有序的，Bob 現在可以轉動棘輪並擦除允許解密儲存在 Google 母艦上的密文的密鑰。 （如果消息是亂序傳遞的，Bob 必須在解密密鑰上多留一會。）
- 在此之後，如果 Alice 和 Bob 遵循了該協議，則沒有人擁有解密密文的密鑰或任何衍生密文的方法。
如果 Bob 決定刪除舊的 Signal 消息（例如，使用“消失的消息”，當然，這是要求對等方尊重的自願請求，並且尊重這是良好的禮儀），那麼 Bob 工作站的未來妥協仍然是’ t 足以解密舊 Signal 消息的密文。
Bob 能否快速輪換他的 OpenPGP 加密密鑰對以達到類似的效果？是的——如果他刪除它們就足以防止過去的密文被解密。 但是沒有 OpenPGP 工具可以自動執行此操作，而且 OpenPGP在每週四不滾動密鑰的情況下已經足夠痛苦，幾乎沒有人願意處理它，而且協議中肯定沒有任何內容可以在每條消息後自動滾動密鑰同時還處理合理的亂序交貨。
那是因為 OpenPGP 是——從現代的角度來看，事後諸葛亮——被設計為 90 年代早期的加密書呆子的玩具，他們將所有時間都用於重新配置他們的電子郵件客戶端來處理，像樂高積木一樣將“簽名”和“加密”混合在一起，而不是像 Signal 那樣促進人類互動的協議，具有密碼學文獻中研究的安全目標。
公平地說，早期的 PGP 設計者在 90 年代隨著 PGP 的發展而發展了大量重要的密碼學文獻——但即使面對人類協議中的基本密碼問題，設計者也放棄了解決這些問題的責任2001 年。儘管當代文獻確切地說明瞭如何解決它，但直到今天，OpenPGP 仍不支持公鑰認證加密。直到 2018 年，當EFAIL說服 OpenPGP 世界勉強強制 MDC 成為強制性時， OpenPGP 甚至沒有實現 20 年來一直是公共密鑰加密的加密標準安全概念——15 年後2002 年對 MDC 的問題發出警告。