摘要

  • RFC 9106 规定了 Argon2 1.3 的输入、参数选择方法和测试向量，却没有为任何实际身份验证集群背书。
  • 可信的运行证据必须把单次调用的参数与并发数、内存高水位、尾延迟、排队、过载行为以及旧参数记录的迁移分布分别记录。

一个登录请求到达服务端。数据库记录指明 Argon2id、版本 19、独立盐值、64 MiB 内存、三次迭代和四条 lane。调用成功，结果也与库的预期相符。看上去，系统已经使用了一种“昂贵”的密码哈希。真正决定服务边界的问题却没有出现：当数百次同样的调用同时发生时，谁来支付这些内存和时间？

RFC 9106 对这条边界其实很坦率。它的参数选择流程先问每次调用能负担多少内存，再问每次调用能等待多长时间，然后调整迭代次数；如果一次迭代已经太慢，就降低内存。这里没有脱离运行环境的安全徽章。算法给出的是一笔必须由部署者兑现的资源预算。

这笔预算被直接写入计算。密码 P、盐 S、并行度 p、输出长度、内存 m、迭代次数 t、版本和类型都会进入初始哈希；可选的秘密值与关联数据也在其中。内存以 1 KiB 块组织，并分成 p 条 lane。lane 在片段内可以并行推进，但会在片段边界同步；额外迭代会再次遍历矩阵。因此，只说“我们使用 Argon2id”并没有交代决定运行成本的参数。

标准建议每个密码使用独立的 16 字节盐。盐能让相同密码不再产生可复用的相同结果，却不是秘密，也不决定一次猜测需要多少工作。验证端必须为每条记录保留确切的版本和参数组合，才能既验证旧记录，也在条件允许时升级它们。

RFC 给出的两组统一建议展示了取舍：第一组是 2 GiB、一次迭代、四条 lane；内存受限方案是 64 MiB、三次迭代、四条 lane。文档还给出基于 2 GHz 处理器的示例，包括四核、八条 lane、4 GiB 和 0.5 秒的后台身份验证情景。这些都是带前提的参考点，并不是对容器、虚拟机、NUMA、内存带宽、分配器或生产集群尾延迟的承诺。

测试向量的作用更窄。它们用固定输入验证中间块和最终标签，例如 32 KiB、三次迭代和四条 lane。测试通过可以说明实现对该用例执行了兼容的运算，却不能说明常驻内存峰值、取消路径、内存清理、调度干扰、排队增长，或者分配失败时服务会做什么。

容量问题就藏在这层缺口里。若一次活跃调用配置 64 MiB，把它乘以并发调用数只能得到规划上限，而非观测结果。库开销、分配器复用和内存带宽都会改变实际表现。服务还必须明确到达边界后的动作：排队、拒绝、限流、超时、卸载其他工作，还是保持失败关闭。悄悄改用更便宜的参数会改变安全主张；任由进程耗尽资源，则会把防御成本变成可用性攻击面。

迁移又制造了第二种错觉。NIST 当前指南要求把方案和成本因子随每条密码记录保存，使未来提高成本成为可能。但“可以迁移”不等于“已经迁移”。新默认值可能只覆盖新密码，以及修改后曾登录并触发重哈希的账户。真正的控制面是存量参数组合的分布、重哈希触发条件、失败升级和仍由旧预算验证的剩余人口。

攻击结论也必须保持克制。内存硬函数提高尝试猜测的资源成本，并迫使攻击者面对时间—空间权衡；它不能告诉我们密码分布、泄露范围、攻击硬件、电价或账户价值。RFC 9106 明确说明自己是 IRTF 的信息类成果，而非互联网标准轨道规范，并提醒研究成果未必适合直接部署。它的权威来自算法和分析的精确性，不是对未被观察过的系统签发证书。

这也划清了本文与 BTW 对 RFC 9807 的报道边界。OPAQUE 把密钥拉伸函数放在客户端，并引出密码不可见性、OPRF 种子托管和记录迁移等问题。本文追踪的是普通服务端验证器：盐、内存、迭代和 lane 在并发到来时，系统到底能负担多少。前者是协议与密钥托管图；后者是容量与证据账本。

一份可审计的运行回执应保留：确切类型与版本、盐策略、m、t、p、标签长度、可选秘密策略；库版本与硬件类别；冷热路径延迟分位数；单次调用和进程内存高水位；同时活跃调用数；队列深度、拒绝与超时；取消和内存清理；CPU 与带宽压力；参数人口分布；重哈希成功与失败；限流、恢复以及失败开放或关闭的行为。一次哈希成功只能位于证据链的开头。

来源

规范与状态：RFC 9106、RFC Editor 记录、IETF Datatracker 记录及 Argon2 论文。设计历史：Password Hashing Competition。验证器要求：NIST 身份验证器指南和 NIST 密码分析。相邻协议边界：RFC 9807。分析框架：最小初始规范、现实层次与运行代码优先。