LWN：Mercurial也要迁移离开SHA-1了！

关注了就能看到更多这么棒的文章哦～

Mercurial planning to transition away from SHA-1

By John Coggeshall
September 28, 2020
DeepL assisted translation
https://lwn.net/Articles/832111/

最近，Mercurial 项目一直在讨论计划从 SHA-1 hash 算法（此算法已经公开的攻击方法了）迁移到更安全的替代算法。到目前为止，讨论还处于算法选择和迁移策略规划的阶段，为用户制定了大致的过渡计划。该项目，目前倾向于 BLAKE2 哈希算法。

2020 年 7 月，Joerg Sonnenberger 开始了对于如何去除 SHA-1 的讨论。Sonnenberger 主要关注了四个方面：使用哪种 hash 函数、需要更新测试集、更新代码库和保持向后兼容。

Picking a new hash

显然，选择新的 hash 算法是项目在从 SHA-1 过渡的过程中面临的最重要的抉择之一。这也是 Sonnenberger 在他的文章中主要关注的地方。他向社区介绍了多种选择，描述了每种选择的好处和缺点。对 Sonnenberger 来说，SHA2-256 是 "最明显的选择"，因为它有广泛的支持（包括在一些 CPU 上的硬件加速）。尽管如此，他还是不太赞成在项目中采用这个算法。

缺点是 SHA2 的结构与 SHA1 相似，许多对 SHA1 的加密分析和由此产生的攻击也适用于 SHA2。在这一点上，SHA2 的主要保护措施只是更大的 hash size，目前还不清楚它的安全边界到底是哪里。在 size extension attach 的情况下，有一些结构日弱点也会适用于我们的使用场景。

SHA2-256 是 Git 项目从 SHA-1 迁移时选择的方向，但该项目不用担心这个 length extension attach（https://en.wikipedia.org/wiki/Length_extension_attack ）潜在漏洞，而 Mercurial 则不同。Mercurial wiki 上关于从 SHA-1 过渡的页面包含了一段与一位不知名的 Git 贡献者（很可能是 brian m. carlson）的对话，他解释了为什么 SHA2-256 length extension attach 与 Git 无关：它会将 type 和 length 作为 object 的前缀来进行 hash 操作。

Sonnenberger 建议中还包括了其他选项，有 BLAKE2、KangarooTwelve（K12）和 BLAKE3。根据他的说法，BLAKE2 是 "在最广泛支持的哈希函数中排名第二"。Sonnenberger 分析了另外两种算法，K12 和 BLAKE3，每种都提供了各自的优点和缺点。

K12 和 BLAKE3 都使用了 SHA3 最终选项之一的 sponge function，只是使用了不同轮数以及不同的 block 组合方案。BLAKE3 方案[并行化方案]较好，这对于大文件和 SIMD 支持来说是个很大的优势，比如 AVX2 和 AVX512 都对大、中等 size 的文件（>4KB）有利。考虑到大量减少的轮数（甚至与 BLAKE2 相比都不如），这里的安全系数有点令人担忧。[…]K12 是基于 SHA3 sponge function 的类似设计。对于中等大小的文件，例如 1-8 KB 的范围，它的扩展性并不好。除了这一点之外，它还是个比较合适的选择。目前 Python 和 OpenSSL 都没有缺省支持这两种算法，所以纯 Python 版本会很慢。

Sonnenberger 提供了一组 "基本测试标准"，用每种算法在他的测试中使用各种实现和配置对一个约 7GB 的文件进行测试。对于每一种算法，他都用汇编器和 C 语言的实现进行了测试。对于 BLAKE3，他既测试了算法的标准版本，也测试了使用与 BLAKE2 相同轮数的变体。结果表明，在 11 项测试中，BLAKE3 的（正常版本）汇编实现速度最快，紧随其后的是汇编版本的 SHA2-256。用 C 语言编写的 SHA2-256 是最慢的。Josef 'Jeff' Sipek 提供了一些额外的性能数据（https://www.mercurial-scm.org/pipermail/mercurial-devel/2020-July/142807.html ），比 Sonnenberger 提供的更详尽。

Augie Fackler 回应了 Sonnenberger，同意他对 SHA2-256 的评估。不过，Fackler 对 Sonnenberger 选择 BLAKE2s 变体（针对 8-32 位平台优化）而不是 BLAKE2b（针对 64 位平台优化）表示质疑。Fackler 表示，他 "多年来一直强烈倾向于 blake2b"，并补充说："谷歌的一位加密专家推荐我使用 blake2b ，所以如果我们不使用 blake2 ，我希望就用这种。" 在 Sonnenberger 的基准测试中，blake2s 在 11 种算法中排名第八，比表现最好的算法（汇编的 blake3）慢了 3 倍多。

Sonnenberger 回应说，选择使用 BLAKE2s 是出于对 32 位系统性能的考虑；BLAKE2b 在 32 位架构上的性能很差。然而，Fackler 则质疑这个优先考虑 32 位平台的想法。

我们为什么要关心 32 位 CPU？不是挖苦，真心话：现在连 Raspberry Pi 的机器都是 64 位的，所以我很不倾向用一个没有经过更多验证的哈希函数来更好地支持这些过时的硬件。

最后，Fackler 和 Sonnenberger 达成了一个协议，默认使用 BLAKE2b，但也为 BLAKE2s 提供 "opt-in"支持可供选择。在 Fackler 看来，这个决定不仅是一个合理的妥协，而且 "很可能会帮助我们在 hg 中拥有一个更通用的哈希选择机制，这样当下一次哈希危机来临时，我们只需要按下一个按钮就可以了。"

Implementation

随着 hash 算法的选择似乎达成了共识，项目面临的困难就是如何实施这些改动。项目的测试套件和代码库本身都需要更新，更不用说还要解决现有存储库的向后兼容问题了。

在 Sonnenberger 看来，最大的痛点是测试套件。根据他的说法，"代码库中的每一个测试都要调整"，至少要替换 SHA-1 changeset 标识符。这似乎没法用简单的搜索和替换来做到，因为有些测试中检查的是 output size 等，而这些会随着新算法而改变。Sonnenberger 建议在当前测试套件的基础上创建一个重复的测试套件来解决这个问题，保持两者都向前发展。然而，Fackler 认为把 changeset hash 从测试中剔除是更好的方法，他写道："我认为我们应该有少量的测试是跟哈希值有关的，而大多数测试应该与此无关。" 目前如何解决测试套件仍然是一个尚未解决的问题。

更新核心代码这个工作，被 Sonnenberger 描述为 "mercurial.nodes"，是 "测试用例之后最大的痛点"。这看起来似乎有悖常理，但 Mercurial 的 revlogs 已经支持 32 字节的哈希值，不像 Git，Git 一直硬编码为 20 字节长度的 SHA-1。然而，Mercurial 确实分配了某些预定义的哈希值来识别版本库中的特殊节点，被用来标记新节点或空节点（这些哈希值的例子可以在这里找到 https://www.mercurial-scm.org/repo/hg-committed/file/tip/mercurial/node.py ）。在这方面，Mercurial 过渡到新的 hash 算法似乎是一个工作量的问题，而不是技术上的困难。

对于最终用户来说，这个规划中最重要的部分，就是如何解决向后兼容性的问题。Mercurial 目前并不支持并行存储多个 changeset hash ，但开发者似乎确实希望向这个方向发展。该项目还希望确保迁移工作只会由版本库所有者来做，而不是作为 Mercurial 特定版本的强制要求。Sonnenberger 建议，存储库可以通过为现有的 changeset 创建 static hash map，将传统的 SHA-1 哈希映射到新的算法来升级。这个 map 可以被兼容层在引用 SHA-1 哈希值的 changeset 时使用。对于在版本库升级后创建的 changeset，所有的哈希值都将使用新算法计算。Fackler 并不喜欢这个想法，但似乎愿意接受，他写道："这很糟糕，因为这意味着迁移时就需要重新克隆，而不仅仅是一个增量 pull 操作了。但如果你要做 migration 的话，这种选项可能就已经算是很好了。"

根据项目的 SHA-1 过渡的 wiki 页面，无论最终选择哪种哈希算法，计划都会选用 truncated version。这种 truncation（目前预计会截掉是一个或两个字节）是为了给 changeset 中识别所使用的 hash 算法类型所需的标志腾出空间。这将伴随着协议层面的 capabilities negotiation，尽管目前关于这一点如何实现的细节还很少。总的计划是让服务器拒绝老客户访问升级后的存储库。

What is next

目前，Mercurial 从 SHA-1 的过渡还是在规划阶段。上次在邮件列表中提出从 SHA-1 迁移的话题是 8 月 15 日。不过，总体来说，该项目仍然很活跃，所以最终很可能完成过渡。该项目仍然有很多悬而未决的问题，正在努力解决，贡献者正在做出合理的工作来确定最佳的前进道路。这种规划很可能可以为现在和未来能选择一个更安全的存储库 hash 算法。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～