Hans Xeng Asked: 2021-04-20 19:14:25 +0800 CST2021-04-20 19:14:25 +0800 CST 2021-04-20 19:14:25 +0800 CST 为什么使用 Deffie Hellmen（密钥交换）而不是使用服务器或客户端的公钥加密对称会话密钥？ 772 如果客户端生成对称会话密钥，然后用服务器的公钥加密并发送给服务器，那么只有服务器可以用它的私钥解密加密的会话密钥，反之亦然。 ssh encryption 1 个回答 Voted Best Answer user1686 2021-04-21T00:43:27+08:002021-04-21T00:43:27+08:00 这样的密钥交换方法确实存在——事实上很长一段时间以来，这是在 SSL/TLS 中交换密钥的主要方式，并且类似的方案是 SSHv1 中唯一可用的交换方法（现已过时）。 但是，这两个系统都已从基于加密的密钥交换迁移到 DH。 您描述的机制有一个主要问题：如果服务器的私钥被盗，它可用于解密以前使用该密钥对建立或将要建立的每一个连接。（换句话说，它缺乏前向保密性。） 考虑到 HTTPS 证书的发行期限为 5 年甚至 10 年，而 SSH 完全依赖于主机密钥一旦创建就不会更改，这可能是一个相当大的风险。（例如，如果同一个攻击者一直在监控数据中心的网络流量……或者如果您居住在参与 PRISM 或 XKeyscore 等监控计划的国家/地区。） （SSHv1 试图通过为密钥交换目的生成临时 RSA 密钥来缓解这种情况，但这完全否定了拥有“已知”服务器密钥来加密事物的优势。而且因为 RSA 密钥生成需要大量的处理，所以它是每隔几个小时完成一次，临时密钥限制为 768 位。） 另一个问题是要求加密能力限制了您对密钥算法的选择。如果我理解正确，非对称数字签名（用于验证 DH 密钥交换）比非对称加密更容易实现，即使对于那些可以同时做到这两者的算法 - 并且并非所有算法都可以。 例如，EC 密钥不能直接用于加密，只能用于签名和密钥交换。有使用 EC 密钥实现加密的方案（例如 ECMQV），但它们实际上是基于 ECDH 密钥交换的。那么，还不如只使用DH。
这样的密钥交换方法确实存在——事实上很长一段时间以来，这是在 SSL/TLS 中交换密钥的主要方式，并且类似的方案是 SSHv1 中唯一可用的交换方法（现已过时）。
但是，这两个系统都已从基于加密的密钥交换迁移到 DH。
您描述的机制有一个主要问题：如果服务器的私钥被盗，它可用于解密以前使用该密钥对建立或将要建立的每一个连接。（换句话说，它缺乏前向保密性。）
考虑到 HTTPS 证书的发行期限为 5 年甚至 10 年，而 SSH 完全依赖于主机密钥一旦创建就不会更改，这可能是一个相当大的风险。（例如，如果同一个攻击者一直在监控数据中心的网络流量……或者如果您居住在参与 PRISM 或 XKeyscore 等监控计划的国家/地区。）
（SSHv1 试图通过为密钥交换目的生成临时 RSA 密钥来缓解这种情况，但这完全否定了拥有“已知”服务器密钥来加密事物的优势。而且因为 RSA 密钥生成需要大量的处理，所以它是每隔几个小时完成一次，临时密钥限制为 768 位。）
另一个问题是要求加密能力限制了您对密钥算法的选择。如果我理解正确，非对称数字签名（用于验证 DH 密钥交换）比非对称加密更容易实现，即使对于那些可以同时做到这两者的算法 - 并且并非所有算法都可以。
例如，EC 密钥不能直接用于加密，只能用于签名和密钥交换。有使用 EC 密钥实现加密的方案（例如 ECMQV），但它们实际上是基于 ECDH 密钥交换的。那么，还不如只使用DH。