TLS 1.3 PSK-握手能转化为PAKE吗？

Question

最近，我们遇到了是否有比SRP所提供的更标准、更高级别的原语的PAKE.这个问题

现在，这让我思考并问自己：TLSundefinedhave a PSK模式，难道我们不能利用它吗？这将是本问题的主题。

我所想象的是以下的交换：

• 客户端->服务器：“嗨，我是potato@po.ta.to”
• 服务器->客户端：“以下是您的关键派生参数：.”而且服务器还发送他的常规密钥交换消息，假设客户端是他声称的那个人。
• 客户端->服务器:发送密钥交换部分

我们的想法是，我们基本上使用哈希密码来做标准的TLS-PSK，这样服务器就可以存储这个哈希版本，而客户端可以动态地重新计算哈希密码( PSK)。

现在至少对于TLS 1.2 这不可能，如果您没有自定义的ClientHello扩展，因为ClientKeyExchange是在ServerKeyExchange之后发送的。

对于TLS 1.3 (草案18)来说，事情更有趣。看来，客户端可以发送一个键标签列表，而服务器选择一个。我不太明白客户端是否还有他的密钥交换部分的信息。

所以现在我的问题非常具体：

我们是否可以在不定义自己的自定义扩展的情况下，将上述登录流安装到TLS 1.3握手中？

Answer 1

当前的带有PSK的TLS 1.3建议草案没有PAKE属性；特别是，客户端可以发送一条消息，获得答复，然后检查字典中的每个条目以搜索服务器使用的PSK。

为此，客户端将发送一个有效的hello，指定客户机感兴趣的标识(以及一个有效的密钥共享)。服务器还将生成其密钥共享，生成基于psk的密钥，以及密钥共享共享秘密，并根据该密钥加密一些数据。然后，客户端计算密钥共享共享秘密(它不依赖于PSK)，然后对字典中的每个条目计算如果该猜测正确的话，密钥将是什么，然后查看该密钥是否将加密区域解密为可读的内容；如果是的话，他已经恢复了PSK。

我相信同样的方法会违背你的建议，有可能是服务器可以进行字典攻击；它是第一个接收密钥加密的消息的人，这是PSK的一个功能。

哈希密码不会添加PAKE属性；攻击者可以同样轻松地散列字典中的每个条目，并使用这些项。

要使TLS1.3成为实现PAKE的工具，正确的方法是将一些带有PAKE属性(例如SRP或EKE)的协议集成到其中。