GNU：一种不良密码学的启发式算法

如果您在系统设计中看到字母GNU，并且该系统与密码学相交，我几乎可以保证它的设计将糟糕到令人震惊的程度。

GnuPG(以及一般的PGP)都是如此，就像建议的GNU名称系统(IETF草案)和加密库(如GNUTLS和libgcrypt)这样的设计一样。事实上，我想不出有哪一个GNU品牌的加密项目不是一堆熊熊大火。

GNS中的区域由公钥/私钥ECDSA密钥对(d，zk)定义，其中d是私钥，zk是相应的公钥。GNS采用曲线25519[RFC7748](也称为。Edwards25519)与ECDSA方案([RFC6979])。

GNU名称系统IETF草案，第2节。

这非常奇怪：特意使用RFC 7748中的edwards25519曲线，但不使用Ed25519签名算法，但仍然选择使用确定性ECDSA(RFC6979)。如果你迷路了，我在之前的一篇博客中写过关于数字签名算法的文章。

作者在RFC草案的第9.1节中承认了他们的设计选择的非常规性质：

GNS在曲线25519上使用ECDSA。这是一个非常规的选择，因为ECDSA通常与其他曲线一起使用。然而，由于Curve25519和EdDSA论文中描述的一系列原因，传统的ECDSA曲线存在问题。直接使用EdDSA也是不可能的，因为在私钥上使用散列函数会破坏GNU名称系统所依赖的线性。据我们所知，没有人建议使用曲线25519而不是另一条类似大小的公共曲线会降低ECDSA的安全性。GNS使用256位曲线，因为这样编码的(公共)密钥适合单个DNS标签，这有利于可用性。

GNU名称系统IETF草案，第9.1节

粗体的说法(我强调的)是无稽之谈：在任何使用数字签名算法的设计中，您的系统都应该将私钥(一些不透明的字节字符串)映射到公钥(其他一些不透明的字节字符串)，并且签名也应该是不透明的字节字符串。在签名算法的幕后包含哈希函数是一个值得商榷的问题，特别是因为RFC 6979还使用HMAC-SHA2来生成确定性随机数，从而使他们选择RFC 6979与其声明的目标相矛盾。

使用带有32字节私钥(而不是64字节私钥)的Ed25519也很简单。也就是说：LibNa为此提供了crypto_sign_seed_keypair()。

但更糟糕的是：ECDSA(菲亚特-沙米尔的变体)比EdDSA(Schnorr的变体)更不安全，速度也更慢。除了这个散列函数非顺序性之外，RFC的作者并没有为这个设计选择辩护。

GNU名称系统项目并没有止步于此。它进一步将Ind-CCA2安全性抛诸脑后，并使用密码反馈(CFB)模式在密码级联中指定使用AES和TwoFish进行加密。

作者甚至没有试图为这一决定辩护。我真诚地怀疑他们在自学过程中是否听说过“自适应选择密文攻击”这个词。

因为，您知道，如果由于数据损坏而发生运行时异常，攻击者肯定永远无法重放UDP流量。

如果你想了解为什么GnuPG(以及整个PGP生态系统)很糟糕，我推荐Latacora‘s Take。

GNUTLS是由创建(然后放弃)libmcrypt的人创建的SSL/TLS库，libmcrypt多年来一直是PHP生态系统中糟糕密码术的祸害(直到它最终在PHP7.2中被删除)。因此，该项目的CVE历史应该不足为奇。

快速故事：几年前，通过Freenode的##加密频道的常规聊天，在libgcrypt中发现了一些定时攻击，包括Taylor“Riastradh”Campbell。这导致我们中的许多人在libgcrypt上寻找更多的bug。

随后讨论的普遍共识是，“我们可能不应该试图修复它们，因为a)这太费力了，因为有太多的坏处；b)对于即将到来的密码分析研究人员来说，这个库将是一个成熟的目标，让他们多年来发表他们的第一篇论文。”事实上，多年来公布的影响libgcrypt的攻击文件并没有让人失望。

如果您在任何与密码学交叉的项目中看到字母GNU-除了它的公共许可证-几乎可以肯定这是一个容易出错的密码设计。