ECDSA具有令人讨厌的特性，即如果密钥对在签名操作中重用随机数，则密码系统将经历私钥泄漏形式的灾难性故障。我听说这被称为“突然死亡”密码学。当然，PS3滥用ECDSA可能是最广为人知的事件。

DJB倡导的诸如Ed25519的密码系统的一个优点是它们没有这个缺点。 Ed25519网站指出，“哈希函数冲突不会破坏该系统。”

ECDSA的完美实现将毫无问题，但是由于实现缺陷是不可避免的，因此使用加密技术而不暴露大量漏洞似乎是可取的尖锐的边缘。

这种情况使我感到困惑，DJB和其他人倡导一种身份验证功能，这种功能在意外重用随机数的情况下表现出“突然死亡”。

使用Poly1305是否真的仅通过性能来告知？如果是这样，为什么如此重要？广泛使用例如HMAC建议MAC计算成本保持不变，并且没有紧迫的问题。我不明白为什么Poly1305在如此危险的情况下会受到如此的欢迎。有人可以解释吗？

#1 楼

Poly1305的一个特别有趣的方面是，只要基础密码是安全的，就可以保证其安全性。换句话说，只要未破坏AES，就可以保证Poly1305-AES是安全的。万一AES损坏，可以用另一种密码替换AES，并获得类似的安全保证。

DJB在其Poly1305-AES论文中谈到了他选择使用随机数的选择：


Poly1305-AES使用随机数有多个原因。首先，没有随机数的可比较协议具有看起来像C（C + D）L / 2 ^ 106而不是DL / 2 ^ 106的安全性边界-这里C是发送方认证的消息数，D是伪造的数量L是最大消息长度-因此不能对大C放心使用。其次，随机数允许AES的调用与Poly1305-AES中的大多数其他操作并行执行，从而减少了延迟。许多情况。第三，由于种种原因，大多数协议仍然具有随机数：例如，随机数是安全加密所必需的，并且随机数允许琐碎地拒绝重放的消息。


评论

$ \ begingroup $
对于它的价值，如果需要，您也可以将随机数与HMAC一起使用。只是安全性不是必需的。
$ \ endgroup $
–杰克·奥康纳（Jack O'Connor）
15年12月31日在16:09
$ \ begingroup $
实际上，假设基础密码是安全的并且您永远不会重复使用随机数，则Poly1305可以保证是安全的。大厦询问为什么添加第二个条件被认为可以接受。
$ \ endgroup $
–雨披
16 Mar 25 '16在05:05

#2 楼

至少就NaCl而言，Poly1305的“突然死亡”特性并不比XSalsa20的差很多。对于任何流密码，如果您将相同的流与两个消息一起重用，则密文的XOR将为您提供明文的XOR。因此，无论您是否依赖Poly1305，随机性重用都已经破坏了您的安全性。

评论

$ \ begingroup $
NaCl用例的另一个因素是，为每个随机数生成一个新的Poly1305密钥。因此，“突然死亡”仅影响带有该随机数的消息。
$ \ endgroup $
–otus
2015年12月31日上午11:09
$ \ begingroup $
为了保护隐私，我们只需要担心发件人选择的随机数，因此，如果其他随机数受到损害，则可能没什么大不了的。但是出于真实性考虑，我们还需要担心攻击者可能选择的随机数，从这种意义上说，即使是一个受感染的随机数也可以使攻击者伪造任意消息。
$ \ endgroup $
–杰克·奥康纳（Jack O'Connor）
17年7月17日在16:52

#3 楼

基于NIST曲线的ECDSA包含一些社区认为可疑的硬编码数字。在密码术中，规则是在对氯的来源存有疑问时将婴儿，浴缸和水扔掉。

DJB曲线（ed25519和c25519的两个变体）不是基于硬编码的数字。它基于易于在标准计算机体系结构上使用的模量。 c25519的选择基于以下事实：该曲线便于DH交换，不需要坐标Y。 ed25519的选择基于其签名场景的方便性，在这种情况下，在高度统一的加法公式中无需考虑无穷大。

SHA1也具有魔术数字，即使社区对其或多或少进行了审查。
Poly1305也没有这种魔术数字。

速度参数取决于实现方式和优化。

基于平面无条件代码的实现更有可能是无错误的。

在过去几年里，随着加密计算需求激增的数据中心，计算成本成为一个问题。

问题不是要在更高层次上解决现有问题（例如在任何加密算法中重用随机数和盐）。问题在于创建无法质疑的加密功能。

评论

$ \ begingroup $
这并不试图回答实际提出的问题。它还声称DJB的动机是完全不受支持的。
$ \ endgroup $
–斯蒂芬·托瑟（Stephen Touset）
2015年2月13日在1:25


$ \ begingroup $
@Stephen：DJB密码（十年前于2005年发布）对兴趣的增长始于Wikileaks（仅几年前）。它们具有“无魔数”的属性。我没有猜测DJB的动机。
$ \ endgroup $
–皮埃尔
2015年2月13日在3:19
$ \ begingroup $
这与实际问题无关。 HMAC是一个可证明的安全构造，即使假设存在多种散列哈希函数也是如此。毫无疑问，加密社区对HMAC的安全性有任何要求。
$ \ endgroup $
–斯蒂芬·托瑟（Stephen Touset）
15年2月13日在4:24
$ \ begingroup $
HMAC基于SHA-1，而SHA-1基于魔术常数。当社区意识到所有加密算法中的魔术常数可能是造成麻烦的原因时，人们将注意力转向了具有相同安全级别，良好的学术审查且没有魔术的算法。这并不是说HMAC是不安全的。这并不是说通过（3个字母的缩写）进行游说之后，标准化ECC是不安全的。这是社区的看法问题。
$ \ endgroup $
–皮埃尔
2015年2月13日在4:32


$ \ begingroup $
HMAC不是基于任何特定的哈希函数。实际上，任何PRF都可以用作HMAC的基础原语。
$ \ endgroup $
–斯蒂芬·托瑟（Stephen Touset）
15年2月13日在7:59