为什么使用 Deffie Hellmen(密钥交换)而不是使用服务器或客户端的公钥加密对称会话密钥?

为什么使用 Deffie Hellmen(密钥交换)而不是使用服务器或客户端的公钥加密对称会话密钥?

如果客户端生成对称会话密钥,然后使用服务器的公钥加密并将其发送到服务器,则只有服务器可以使用其私钥解密加密的会话密钥,反之亦然。

答案1

这种密钥交换方法确实存在——事实上,很长一段时间以来,这是基本的在 SSL/TLS 中交换密钥的方式,并且类似的方案是 SSHv1(现已过时)中唯一可用的交换方法。

然而,这两个系统都已经迁移基于加密的密钥交换到 DH。

您描述的机制有一个主要问题:如果服务器的私钥被盗,则可以用它来解密每一个连接之前使用该密钥对创建的或将来使用该密钥对创建的。(换句话说,缺乏前向保密

考虑到 HTTPS 证书已经颁发了 5 年甚至 10 年,而 SSH依赖由于主机密钥一旦创建就不会改变,因此这可能非常危险。(例如,如果同一个攻击者一直在监视数据中心的网络流量……或者如果你居住在参与 PRISM 或 XKeyscore 等监视计划的国家。)

(SSHv1 尝试通过生成临时 RSA 密钥用于密钥交换来缓解此问题,但这完全抵消了使用“已知”服务器密钥来加密的优势。而且由于 RSA 密钥生成需要大量处理,因此每隔几个小时才进行一次,并且临时密钥限制为 768 位。)

另一个问题是需要加密功能限制你选择密钥算法如果我理解正确的话,非对称数字签名(用于验证 DH 密钥交换)比非对称加密更容易实现,即使对于那些算法来说可以两者皆可——但并非所有人都能做到。

例如,EC 密钥不能直接用于加密,只能用于签名和密钥交换。有些方案使用 EC 密钥实现加密(例如 ECMQV),但它们实际上基于ECDH密钥交换。那么还不如就使用 DH。

相关内容