为什么TLS中没有“临时非DH EC”密钥交换？

Question

在RSA密钥交换中，客户端选择一个主密钥并使用服务器证书中的RSA公钥对其进行加密，并将其发送给服务器。这没有提供任何前向保密。

在ECDHE密钥交换中，客户端和服务器都生成临时的EC密钥对，并使用DH密钥交换来协商主密钥。服务器公共临时公钥使用服务器身份验证证书进行签名。这就给出了秘密。

在后者中，服务器和客户端必须生成两个短暂的密钥对。以下两个不需要客户端生成EC密钥对的密钥交换方法的组合如何：

1. 服务器生成临时EC密钥对，使用服务器身份验证证书对公钥进行签名。
2. 服务器向客户端发送短暂的EC密钥对公钥。
3. 客户端选择一个预选密钥，使用服务器临时的EC公钥对其进行加密，并将其发回。

ECDHE不可避免的不利因素是什么？我没看到一个明显的安全漏洞。使用EC密钥加密可能有困难吗？

Answer 1

“可能很难使用EC密钥来加密吗？”；是的，因为没有可以使用的直接EC加密原语。ElGamal EC加密是可能的，但它需要各种技巧才能使其工作。例如，有消息到EC点的映射。有ECIES，但这实际上可以归结为首先执行ECDHE，还有一个缺点就是需要一个密码。

除此之外，对于RSA，密钥对生成是您可能看到的最慢的算法之一。这不仅是缓慢的，但它也是非常不可预测的，因为它是未知的，当两个所需的素数被找到。在欧共体，这是非常容易的：

1. 在1和N之间创建一个随机数(排他性)；
2. 用基点G执行该数字的点乘以到达公共点。

所以基本上它和卫生署的行动一样快。根本就没有时间等待质数的产生。因此，由于关键一代本身并不构成太大的问题，因此也没有迫切需要改变。

TLS 1.3的一个重要想法是减少往返次数。它甚至对初始密钥协议的另一端的算法进行了猜测。然后，它可以立即将客户端的临时公钥发送到服务器，服务器用服务器的临时公钥进行响应，以设置通道。这样，只需两条消息就可以(并且将)设置加密的通道。使用加密，客户端(必须启动连接)首先请求公钥，接收它，然后使用它进行加密。

也就是说，如果客户端不使用会话恢复，ECDH会加快速度，这是一个单独的加快速度的技巧。

另一个较小的区别是，ECDH中的随机密钥现在依赖于双方的随机数据。不同的客户端可能具有随机数产生器的不同优点，而秘密加密的缺点是秘密本身不是完全随机的，例如当使用RNG时不具有密码安全性。然而，使用ECDH确实意味着一个完全失败的RNG将完全显示已建立的共享秘密，因为短暂的私钥可能会被知道。

还请注意，简单地降低选项的数量是TLS 1.3中的一项重要举措。仅仅为了它而有选择只会使协议更不安全，而不是更安全。对于用于特定加密套件的不同算法(不包括用于身份验证的证书的安全性级别的差异)，IMHO甚至没有意义。