前向保密是否被誇大或有必要？
前向保密，也是完美的前向保密，即使私鑰被洩露，也可以保證會話密鑰。這是通過在不使用確定性生成算法的情況下為每個會話生成一個隨機密鑰來實現的。
在這個答案的引述中， Thomas Pornin說
重複使用加密密鑰與前向保密背道而馳，而前向保密已成為一個賣點（儘管在我看來它有點被誇大了）。
雖然幾乎在所有地方都建議使用前向保密，但為什麼應該有點誇大其詞？
由於我在原始報價的來源，我不妨回應……
從技術上講，前向保密被誇大了*，因為*它幾乎在任何地方都被推薦。在某些情況下，它是有意義的並且是有價值的財產。在許多其他情況下，它的意義不大，雖然從安全的角度來看是無害的，但它可能會引發與性能相關的問題。
假設您有兩個系統想要通過不安全的網路交換機密數據。這是 TLS 協議的上下文。在某些時候，數據會使用從 TLS 握手中使用的密鑰交換協議派生的密鑰進行加密。前向保密是一個屬性，基本上，一旦交換結束，相關方不會保留所有允許解密的秘密資訊：數據已在發送方加密，並由接收方解密，沒有人（當然攻擊者除外！）需要再次解密，因此可以刪除加密密鑰。如果 TLS 客戶端和伺服器使用 RSA 密鑰交換，那麼該協議是不安全的，因為 RSA 解密密鑰是伺服器的長期密鑰，對應於其證書中的公鑰，這些將作為只要證書本身，通常是幾個月或幾年。
在這種情況下，如果攻擊者記錄加密會話，則攻擊者可以利用非轉發安全密鑰交換，然後設法破壞伺服器以獲取解密密鑰。這假設攻擊者可以以某種方式預測他將能夠在以後破壞伺服器，因此值得記錄加密會話。這在許多情況下是不合理的，例如涉及 Web 瀏覽器與 Web 伺服器通信：攻擊者根本不知道他何時或是否會訪問伺服器，如果目標是獲取（例如）信用卡號碼，攻擊者不會費心記錄以前的會話；他將簡單地掠奪伺服器端數據庫，一旦伺服器本身受到破壞，他將可以很好地訪問該數據庫。
儘管如此，在現實生活中，前向保密非常有用。其中之一是典型的端到端加密消息系統。許多特性使得此類系統非常需要前向保密：
- 加密數據的總量遠小於典型的 Web 瀏覽會話（讓我們面對現實吧，今天的 Web很胖）。此外，在某些消息傳遞系統中，加密消息已經由管理傳輸的伺服器記錄，用於非同步傳遞。
- 過去的對話對攻擊者來說很有趣，並且不一定會通過破壞一台設備來提供給他們（這取決於系統在記憶體方面的策略）。
- 小組對話意味著小組管理，特別是能夠將前小組成員排除在後續討論之外；這本質上需要某種前向保密（現代用語中的“棘輪”）。
不過，我的觀點是，對所有地方的前向保密一攬子建議“有點誇大其詞”，因為它確實是一攬子的、普遍的建議，在所有情況下都被視為不可避免的要求，而許多情況下並不需要它.
**不利的一面是，**這是由通用前向保密要求引起的性能問題。在TLS 1.3中，系統地強制執行前向保密。假設一些小型嵌入式設備必須通過相互的、基於證書的身份驗證與伺服器通信。還假設使用橢圓曲線密碼術。將發生以下情況：
- 客戶端生成一個新的 ECDH 密鑰對，即隨機整數a和曲線點aG（對於正常生成器G）。
- 伺服器還會生成一個新的 ECDH 密鑰對（b，bG）。
- 伺服器簽署其公共部分bG；簽名將使用 ECDSA 或 EdDSA，並涉及計算生成器G與新標量的乘法。
- 客戶端驗證簽名。這需要執行兩個點乘法，其中一個點是生成器G，另一個是伺服器的公鑰。有一些技巧可以以某種方式使這兩個點乘法中的一些操作相互化，但它們需要額外的 RAM，而這在嵌入式系統中始終是一種稀缺資源。
- 客戶端通過將接收到的bG與a相乘來終止 ECDH 密鑰交換。
- 伺服器還通過將接收到的aG與b相乘來終止 ECDH 密鑰交換。
- 客戶端必須自己使用自己的長期密鑰計算簽名，以便伺服器知道它與正確的客戶端對話。
總的來說，客戶端需要計算五個點乘法，其中三個在傳統的生成器G上（因為這個生成器是預先知道的，這允許一些優化，所以G的乘法比一個新的收到點）。伺服器上的成本是相似的。
現在，將其與TLS 1.2進行比較。使用 TLS 1.2，上述所有操作都可以以大致相同的方式完成（消息的編碼不同，但加密結果將是相同的）；這將使用“ECDHE_ECDSA”密碼套件（ECDHE 密鑰交換，由伺服器使用其 ECDSA 私鑰簽名）。但是，TLS 1.2 還提供“ECDH_ECDSA”密碼套件，沒有 ECDHE 的最後一個“E”（表示“短暫”的那個）。在理想情況下，會發生以下情況：
- 伺服器有一個長期的 EC 密鑰對（b，bG）。公共部分（bG）在其證書中，即已在密鑰生成時計算。
- 客戶端還有一個長期的 EC 密鑰對（a，aG），其中aG編碼在其證書中，同樣是密鑰生成時間。
- 客戶端和伺服器相互發送他們的證書。
- 客戶端計算a ( bG ) 作為 TLS 連接的預主密鑰（實際的加密密鑰將通過一些基於 HMAC 的函式從預主密鑰派生，其中還包括握手期間交換的隨機值）。
- 伺服器計算b ( aG ) 作為 TLS 連接的預主密鑰。
就是這樣。客戶端和伺服器現在必須分別計算一個單點乘法。這被稱為“靜態-靜態 Diffie-Hellman”。
靜態-靜態 Diffie-Hellman 密鑰交換不是在 TLS 1.3 中允許，因為它不是前向安全的。橢圓曲線密碼學的現代實現速度很快，任何體面的伺服器都可以毫不費力地為每個客戶端計算五點乘法；一個像樣的 x86 CPU 可以用單核每秒執行 30000 點乘法！但是，在客戶端，情況可能會有所不同：一個非常小的嵌入式系統，例如時鐘頻率為 5 MHz 或更低（以節省電力）的 ARM Cortex M0+，每個點乘法將需要接近一秒。對於這樣的客戶端，成本乘以 5 肯定是不可忽略的，並且可能是“非前向安全連接”和“因為前向安全交換太昂貴而根本不加密”之間的區別。無論您認為前向安全性是多麼不可或缺，
從這個意義上說，TLS 1.3 比 TLS 1.2 對小型嵌入式系統更具敵意，這是為了強制前向安全性，即使在它沒有帶來任何實際優勢的情況下也是如此。這就是我所說的“有點誇張”。