不推荐使用SHA1

嗨，我现在转向这个邮件列表，寻求如何处理基于SHA1的自我签名的建议。我有两个具体的问题，在电子邮件的底部。但首先，我想介绍一下具体的问题和我到目前为止的想法。基于SHA-1是一篇乱七八糟的文章[1]，我们决定更改Sequoia以拒绝默认使用SHA1的签名[2]。这既包括数据签名，也包括所有类型的自签名，包括主键绑定签名(也称为Backsigs)。[1]https://sha-mbles.github.io/[2]https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html#method.reject_hash_atA Secure Drop Developer最近与我们联系，并指出我们的策略过于严格：一些安全Drop安装具有使用sha1的脱机密钥，用户没有轻松的方法(或缺乏意愿)更新这些密钥。这促使我调查sha1的一般使用情况。不幸的是，似乎许多来自技术成熟用户的频繁使用的证书仍然依赖sha1。我的调查结果如下：https://gitlab.com/sequoia-pgp/sequoia/-/issues/595First，我发现微软创建不到一年(2019年10月)的安全通知PGP密钥[3]使用的是SHA-1。考虑到首选电子邮件编码@pgp.com符号的使用，我怀疑他们使用的是赛门铁克PGP产品。[3]https://www.microsoft.com/en-us/msrc/pgp-key-security-notificationsLooking在Debian Keyring，我发现：-884个证书中的106个(12%)使用sha1作为所有用户ID绑定签名和直接密钥签名-63个(7%)使用sha1来保护至少一个未撤销的用户ID。-234个具有不可撤销的实时签名能力的子密钥-其中19个具有绑定签名，以某种方式使用了sha1(8%)。对子密钥绑定签名使用更强的标记，但对Backsig使用-9\f25 SHA1-9\f6。[4]OpenPdebian开发人员可能是最老练的https://dev.gnupg.org/T5110As用户，这是相当糟糕的。对于ArchDebian开发人员来说，情况更糟：5个主("；CA&34；)密钥中有2个依赖于SHA1.。在72个开发者密钥中，26个(36%)使用SHA1进行所有用户ID自签名和直接密钥签名。在剩余的46个证书中，有2个使用SHA1作为未撤销的、支持实时签名的子密钥。查看Fedora项目的签名密钥[5]：所有7个证书都独占使用SHA1。当我与负责此基础设施的人员交谈时，我们发现这是由于配置错误造成的，他们立即修复了该错误。[5]https://getfedora.org/static/fedora.gpgGiven这些结果后，我们决定重新评估我们糟糕的SHA1列表。由于SHA1的论文指出SHA1的前像阻力没有损坏，我想我们或许可以接受SHA1用于自我签名，而不是用于文档[6]。但是，阿祖尔指出[7]马洛里可能会造成文档和自签名的冲突，然后说服爱丽丝在文档上签名。这在实践中是可行的，因为Mallory可以预测签名中的所有内容，除了时间戳，如果Alice是自动签名服务，那么Mallory很有可能能够让Alice在正确的时间签署文档。[6]https://gitlab.com/sequoia-pgp/sequoia/-/issues/595[7]https://gitlab.com/sequoia-pgp/sequoia/-/issues/595#note_433768966If签名包括盐，如果马洛里强迫爱丽丝用正确的元数据在文档上签名，那就难得多了。因此，我们计划在红杉制作的所有签名中加入一种盐，这样如果SHA256遭受与SHA1相同的命运，我们仍然可以依靠前像阻力来允许我们在一段时间内继续接受使用SHA256的自我签名[8]。[8]https://gitlab.com/sequoia-pgp/sequoia/-/issues/597So，有两个问题：-今天有没有人看到接受sha1自签名的安全方法？或者(哎呀！)，如果我们想要安全，我们需要说服大约10%的经验丰富的OpenPGP用户重新签名或重新生成他们的密钥吗？-人们对在散列中加入盐以使散列内容更难预测(如[7]所述)有何看法？谢谢！：)Neal