TLS 1.3密码套件SHA级别

Question

由于我喜欢只用最优质的金属制作锡箔帽，我很高兴看到Firefox/NSS (我使用的是Arch Linux)最近增加了对P-521 ECDH组的支持，与TLS 1.3兼容(尽管不是套件B的一部分)。

长期以来，它一直使用secp521r1命名曲线支持ECDSA公钥，支持AES256 (以某种形式)很长时间。

在我看来，这是很长一段时间(或可能的任何时候)以来第一次，考虑到密码堆栈中其他组件的弱点，现在能够真正实现256位有效的对称安全性。

我的假设是基于一篇引用的学术论文他看不出有必要为这个问题找出答案，但这是由顶尖人物提出的。，其中列出了一个给定对称密钥长度的RSA和EC术语中相应的公钥长度。本文认为2048 are基本等价于112位，EC密钥长度约为对称密钥强度的一半(即secp256k1 == 128位)。

现在，TLS1.3的最大SHA2级别为384位，火狐在这方面没有超过标准。正在部署的具体密码套件是ECDH-美学256-GCM 384 (w/ P-521)。

我向crypto.SE提出的问题是--让客户端浏览器支持最大限度的SHA384，在加密安全性方面，我损失了什么？

我的问题有两个支持的增编/子查询:首先，考虑到我使用的是一个AEAD (AES256GCM)密码，校验和似乎与我无关。我在这里错过了什么？

其次，如果我不知何故遗漏了重点，并且(推测) SHA384以某种方式引用了与堆栈中的ECDH组件有关的身份验证--我在这里是否有风险(假设攻击者可以为SHA384找到冲突，而不是SHA512)，攻击者可以向我的通信中注入虚假消息，还是它(非常远程)可以增强攻击者解密我的通信的能力？

最后，我很清楚，在我的攻击面积中最薄弱的环节是在许多比密码原语更容易的地方，然而，为了好的锡箔和我的强迫症，得到一些指导是非常好的。

最后--哦，世界上的每一个浏览器和密码库都支持AES、Threefish、量子抵抗标志、Ed448 (我会用其他人来交换)、SHA3、Twofish等等，这将是多么好啊。添加所有这些浮肿，让实现者明智地配置和选择。

Answer 1

首先，考虑到我使用的是AEAD (AES256GCM)密码，校验和对我来说似乎无关紧要。我在这里错过了什么？

您所缺少的是TLS如何处理指定的散列。与您的假设相反，它不会在每条记录中添加散列；正如您所指出的，这将是愚蠢的。

相反，它使用它有两个目的：

• 在密钥派生函数中，即作为将P521共享机密和公共数据映射到实际密钥的基础结构的一部分。
• 总结交换记录(以检测降级攻击)

这就引出了你的下一个问题：

我的风险(假设攻击者可以为SHA384找到冲突，而不是SHA512)是攻击者可以向我的通信中注入虚假消息，还是(非常远程)可以增强攻击者解密我的通信的能力？

如果攻击者试图侦听两个诚实方之间的协商，他将无法选择散列的内容；这意味着冲突攻击将不适用(因为冲突攻击假设对手有能力选择两个哈希值到同一个值)。而且，即使对手能够注入他选择的明文(例如通过Javascript applet)，这也不会有帮助，因为散列是由TLS实现而不是应用程序选择的。

我向crypto.SE提出的问题是--让客户端浏览器支持最大限度的SHA384，在加密安全性方面，我损失了什么？

你似乎一点也不缺，系统的其他部分似乎更容易受到攻击。