FreeBSD pkg 2.8.0 发布后将逐步弃用 SHA-256，转而使用 Blake2b 作为校验和（旨在应对量子计算威胁？）
你好，我是无能。
在 Github 的时间线上刷到了 freebsd/pkg 的发布信息，偶然间看到了 Blake2b 这个词。
https://github.com/freebsd/pkg/releases#release-2.8.0
- Blake2b used everywhere possible for checksums; repositories use blake2 instead of sha256
其实 Blake2b 本身在 2016 年就已经被包含在 GNU coreutils 的发布中了。
Blake2b 到底是什么
之前只是简单查了一下，只知道它是一种哈希算法，所以稍微确认了一下。
用 Rust 实现 Blake2(Blake2b) #Security - Qiita
Blake2 有两种，普通版 Blake2b 和缩减版 Blake2s。Blake2b 用于 64 位系统，Blake2s 用于 8~32 位系统。
原来如此。
RFC:
RFC 7693 - The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)
它也是 Argon2 密码哈希中使用的算法。关于未来的替换趋势，是否会变成：密码哈希将目前使用 bcrypt 的实现替换为 Argon2，而加密哈希将目前使用 SHA-256 的实现替换为 Blake2，从而成为一种现代化的设计呢？
考虑到目前已经能看到不少实现开始使用 Argon2，我觉得这种可能性是存在的。话虽如此，像 md5sum 这样轻量且快速的哈希算法至今仍在使用，如果只是为了简单地校验一致性，它依然很方便。甚至 WebSocket 在 WebSocket 握手中也是基于使用 SHA-1 的前提写在 RFC 中的，但对于 WS 的实现来说，根本没有更换的必要，所以文档中也对此做了说明。
本文件中描述的 WebSocket 握手不依赖于 SHA-1 的安全属性（如抗碰撞性或抗第二原像攻击性等）（详见 [RFC4270]）。
RFC 6455 - The WebSocket Protocol
既然这个问题可以找人探讨，我就问了 ChatGPT (GPT 5.6)。
结论是，向 Argon2 迁移作为现代化改造是合适的，但作为加密哈希，这更像是多了一种选择。
不过，FreeBSD 切换了 pkg 的 checksum 使用方式确实让人感到相当惊讶，所以这在未来是否会成为某种标准，还不好说。
以下是对 GPT 5.6 的提问。
Q. 密码哈希将目前使用 bcrypt 的实现替换为 Argon2，而加密哈希将目前使用 SHA-256 的实现替换为 Blake2，这会成为一种现代化的设计吗？
A. 是的， 对于密码存储，从 bcrypt 迁移到 Argon2id 完全可以称得上是“现代化”。另一方面， 将通用加密哈希从 SHA-256 迁移到 BLAKE2，并不一定是一种简单的时代更替。
如果是密码的话，目前的优先级大致如下：
| 用途 | 传统 | 当前推荐 |
|---|---|---|
| 密码存储 | bcrypt | Argon2id |
| 密码存储的替代方案 | PBKDF2 / scrypt | Argon2id / scrypt |
| 通用哈希 | SHA-256 | SHA-256 / SHA-3 / BLAKE2 / BLAKE3 |
| MAC | HMAC-SHA256 | HMAC-SHA256 / keyed BLAKE2 |
| 快速一致性校验 | SHA-256 | BLAKE2 / BLAKE3 |
OWASP 也将 Argon2id 作为新系统的首选，而将 bcrypt 主要定位为面向现有系统。由于 Argon2id 不仅考虑 CPU 负载，还是 一种将内存使用量纳入攻击成本的 memory-hard KDF，因此在抵御使用 GPU/ASIC 进行大规模尝试的密码破解方面，设计上比 bcrypt 更具优势。（OWASP Cheat Sheet Series）
例如，如果是新实现，
password
↓
Argon2id(
salt = random 128bit,
memory = 64 MiB,
iterations = 3,
parallelism = 适当值
)
↓
$argon2id$v=19$m=65536,t=3,p=...这样的结构是很自然的。RFC 9106 也推荐使用 Argon2id。（RFC Editor）
另一方面，
SHA-256 → BLAKE2的情况则有所不同。
SHA-256 并没有因为古老而变得危险。
目前还没有针对 SHA-256 的实用碰撞攻击或原像攻击，在普通的加密用途中，它依然足够强大。
BLAKE2 的优势主要在于：
速度快
+
安全性高
+
标准支持 keyed hashing
+
易于实现所以，
旧式 现代化
bcrypt ───────→ Argon2id
↑这样的理解比较接近。
倒不如说在当前的设计中，
Password
└─ Argon2id
Cryptographic digest
├─ SHA-256
├─ SHA-3
├─ BLAKE2
└─ BLAKE3
Message authentication
├─ HMAC-SHA256
└─ keyed BLAKE2像这样根据用途进行选择才是现代的做法。
特别是在自己设计新软件时，如果没有协议兼容性等限制，我认为可以按照以下思路考虑：
Password hashing
→ Argon2id
通用高速哈希
→ BLAKE2b / BLAKE3
重视与外部标准/协议的兼容性
→ SHA-256
MAC
→ HMAC-SHA256
或 keyed BLAKE2此外，BLAKE2 和 BLAKE3 非常重要。如果是为了“在新设计中想使用比 SHA-256 更新的高速哈希”这一目的，那么在 2026 年，不仅是 BLAKE2，也应该将 BLAKE3 纳入候选。BLAKE3 在并行化、SIMD 以及大文件哈希处理方面速度极快。
不过，
SHA-256 → BLAKE3这与其说是“出于安全考虑抛弃 SHA-256”，不如说是：
为了获取性能和 API 设计上的优势而做出的选择
。也就是说，问题中的两者并不等同，
bcrypt → Argon2id
作为安全设计，是明确向现代化演进的方向。
SHA-256 → BLAKE2/BLAKE3
并非安全必须的迁移，而是基于性能和易用性考虑在进行新设计时做出的选择方向。
两者存在这样的区别。
如果将范围扩大到“如果在 2026 年从零开始设计一套包含认证、签名、加密和文件哈希的 API，该如何选择”，那么以 Argon2id / BLAKE3 / XChaCha20-Poly1305 / Ed25519 / X25519 为核心，将构成一套相当现代化的架构。