完全正向保密（perfect forward secrecy）是信息安全中提出的觀點。要求一個密鑰只能訪問由它所保護的數據；用來產生密鑰的元素一次一換，不能再產生其他的密鑰；一個密鑰被破解，並不影響其他密鑰的安全性。設計旨在長期使用密鑰不能確保起安全性的情況下而不影響過去會話的保密性。
歷史,適用的協定,前向保密,前景,實現原理,實現方式,
歷史
前向保密由Whitfield Diffie、Paul van Oorschot、Michael James Wiener這幾位提出的概念。它用來描述一個屬性站對站協定(STS)，其所述的是使用長時間的密鑰來加密。
IEEE 1363-2000中附錄D.5.1，對其性質進行了相關描述。
適用的協定
IPsec的可選功能(RFC 2412)
SSH
SSL/TLS協定
前向保密
前景
2014年時候，由於心血漏洞（存在伺服器私鑰泄漏的可能），沒有使用前向保密的站點，加密通信的數據可以通過私鑰來解密，導致信息泄漏，這使得前向保密被重視起來。
實現原理
如果伺服器的私鑰泄漏，任何可以訪問私鑰的人都可以在會話建立時解密訊息查看會話密鑰，然後用會話密鑰解密會話中交換的所有數據。所以確保你的私鑰絕對私密至關重要，千萬不要把它們暴露在你自有的系統之外。
但有時私鑰確實會泄漏，或者因為系統被黑，或者因為有訪問許可權的內部人士，或者因為政府的命令。如果你知道密鑰已經暴露了，可以生成新的公私密鑰對和新的證書，把舊證書撤銷掉，這樣客戶端就不會再接受它（這一步很重要，否則拿到舊私鑰的人仍然可以用舊證書冒充你）。但這樣只是照顧到了將來的數據交換，如果竊取了私鑰的人監測並記錄下了以前的會話，他們仍能用舊密鑰解密並查看以前會話中交換的數據。
有種安全連線的保護方法甚至連這種回溯性破解也可以防護。它被稱為“完全正向保密（perfect forward secrecy）”，它為客戶端和伺服器端提供了一種為會話創建共享密鑰的辦法，而這個密鑰不會暴露給任何監測數據交換的人（即便監測者能夠得到伺服器的私鑰，只要它只是個監測者而不是中間人）。
正向保密的標準實現是採用某種Diffie-Hellman 密鑰交換。Diffie-Hellman 的基本思想是利用整數模素數群的乘法性質。計算某個數的冪在群中的值很容易，即便這個群和冪都很大也沒關係。但用已知的數學知識做逆向計算非常困難，即給定一個數和一個值，很難根據這個群中的值算出這個數的冪是多少（這被稱為離散對數問題）。Diffie-Hellman 密鑰交換的雙方都使用相同的群和原根，但所用的冪和生成的值不同，然後他們互相交換由各自的冪生成的值。最終雙方都得到了一個結合了兩個私密冪的共享值。任何監測數據交換的人要想得到私密冪，都要做逆向工作去解決計算困難的離散對數問題，並且只要值足夠大，以現有的技術計算出結果所需要的時間讓這種計算失去了實際意義。
實現方式
但對瀏覽器來說有個壞訊息，很多web伺服器都不支持安全連線的完全正向保密。部分原因是這樣會增加一些開銷（用基於橢圓曲線的Diffie-Hellman變體代替離散對數可以降低這種開銷），但經常僅僅是因為用了過時的安全實現。Google在對正向保密的支持上非常積極主動，並且其他主流網站也開始支持它了。在Chrome瀏覽器中，你可以點擊綠色鎖圖示查看某個安全站點是否使用了完全正向保密（可以在連線的詳細信息中看看它是否給出了包含字母"DHE"的密鑰交換，比如“ECDHE_RSA”）。
在Java程式代碼中要求使用正向保密相當容易。還是使用系統屬性，https.cipherSuites=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA。如果你想控制每條連線上的協定，可以採用跟控制協定版本號相同的辦法，請參考github 代碼庫中的com.sosnoski.tls.ForceSuite類。
那個密碼套件的名稱看起來相當神秘，但如果把它拆開來看就很好懂了。 “TLS” 自然是指TLS協定。 “ECDHE” 是說使用帶有短暫性密鑰的橢圓曲線Diffie-Hellman密鑰交換（也就是說要為每個會話創建新密鑰並且事後也不會記下來）。“RSA”表明用RSA 非對稱加密保護TLS握手的安全。 “AES_128_CBC” 是說在密碼塊連結模式中用帶有128位密鑰的AES 非對稱加密保護真正的數據交換。最後的 “SHA” 表明用 SHA 安全哈希算法。
這可能是在Oracle的Java 7上用TLS 1.1所能用到的最好密碼套件。如果用TLS 1.2 ，你可以升級成TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256，使用更強(也更安全)的 SHA2 摘要算法。理想情況下，用GCM（伽羅瓦/計數器模式）之類的模式代替CBC更好，但Oracle的 Java 7 JSSE (Java 安全套接字擴展)實現還不支持。
這裡可能還要考慮從 “ECDHE” 去掉“EC”。密碼學大師布魯斯·施奈爾現在推薦優先選用離散對數而不是橢圓曲線加密。橢圓曲線技術更快，但可能會有政府組織故意引入的弱點。但大多數商業安全網站只支持Diffie-Hellman的橢圓曲線版本，所以這個例子裡就用它了。
在服務端一般用套用伺服器上的配置選項控制密碼套件。比如在使用帶Java連線器的Tomcat時，可以用<Connector>元素上的ciphers屬性限制密碼套件，所以跟上面客戶端的配置相匹配的應該是<Connector … ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA" …/>。而在用 APR 連線器時應該是SSLCipherSuite屬性。
