完全正向保密

完全正向保密（perfect forward secrecy）是信息安全中提出的观点。要求一个密钥只能访问由它所保护的数据；用来产生密钥的元素一次一换，不能再产生其他的密钥；一个密钥被破解，并不影响其他密钥的安全性。设计旨在长期使用密钥不能确保起安全性的情况下而不影响过去会话的保密性。

历史
前向保密由Whitfield Diffie、Paul van Oorschot、Michael James Wiener这几位提出的概念。它用来描述一个属性站对站协议(STS)，其所述的是使用长时间的密钥来加密。
IEEE 1363-2000中附录D.5.1，对其性质进行了相关描述。

适用的协议

IPsec的可选功能(RFC 2412)
SSH
SSL/TLS协议

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属性。