Argon2哈希生成
在浏览器里用自研的 RFC 9106 Argon2id / Argon2i / Argon2d 实现生成密码哈希：可调内存、迭代次数与并行度，输出十六进制、base64 与 PHC 字符串（$argon2id$v=19$m=…），并给出实际生效的内存与耗时。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
输入与参数
本工具是自研的纯 JS Argon2 实现（BigInt 完成 64 位运算），结果与 RFC 9106 的三组官方测试向量、Node 的 crypto.argon2Sync 以及 phc-winner-argon2 命令行一致。所有计算都在浏览器本地完成，密码与盐不会离开这个页面。
结果
设置好参数后点击「生成哈希」。盐默认填了 "somesalt" 的十六进制，方便对照 RFC / CLI 的结果。
这个工具能做什么
- 给用户密码选一个合适的哈希参数：把内存、迭代次数、并行度分别调一遍，看耗时怎么变，从而定下自己服务端能接受的配置。
- 对照别人给的结果：同事或文档给出了一条 `$argon2id$v=19$m=65536,t=3,p=4$…` 字符串，用它里面的盐和参数在这里复算一遍，确认自己实现或库的行为一致。
- 教学与验证：Argon2 的「内存硬」体现在哪？把内存从 8 KiB 调到 32 KiB，观察耗时几乎线性增长，比读文档直观。
- 生成一条可以直接粘进配置或测试夹具的 PHC 字符串（含盐与参数），避免自己拼接 base64。
示例
输入
密码 password，盐 736f6d6573616c74（"somesalt" 的 UTF-8 十六进制），变体 Argon2id，内存 32 KiB，迭代 3，并行度 1，输出 32 字节
输出
十六进制摘要 6d4c5fa26a057c23e3a4f72ae34c64e71398c851f2c79464e3e670ed41b543f9；PHC 字符串 $argon2id$v=19$m=32,t=3,p=1$c29tZXNhbHQ$bUxfomoFfCPjpPcq40xk5xOYyFHyx5Rk4+Zw7UG1Q/k
这组参数足够小（32 KiB），浏览器里瞬间出结果；同样的输入用 phc-winner-argon2 命令行 `printf password | argon2 somesalt -id -t 3 -k 32 -p 1 -l 32 -r` 得到完全相同的摘要。
常见问题
这是真的 Argon2 吗，还是用别的算法顶替的？
是真的 Argon2。本页把 RFC 9106 定义的 H0 预处理、H' 变长摘要、内存矩阵填充、BlaMka 压缩函数与索引函数都用纯 JS 重写了一遍，并且单测里逐字节比对了 RFC 官方三组测试向量（Argon2d / Argon2i / Argon2id，m=32 KiB、t=3、p=4），另外还与 Node 的 crypto.argon2Sync 和 phc-winner-argon2 命令行交叉验证。64 位运算用 BigInt 完成，所以比原生实现慢很多。
生产环境该怎么选参数？
先按官方建议起步：Argon2id、内存 64 MiB、迭代 3 次、并行度等于可用核数（常见 4），摘要 32 字节。然后用自己服务器的基准数据调整，目标是单次哈希 0.3–0.5 秒。注意浏览器里的纯 JS 实现慢几十倍，这里的耗时不能直接当成服务端指标。
Argon2id、Argon2i、Argon2d 该选哪个？
选 Argon2id（也是 RFC 与 OWASP 的推荐）。它第一轮的前半段使用数据无关寻址，能抵抗缓存时序侧信道；后半段与后续轮次使用数据相关寻址，保留了对 GPU / ASIC 的抵抗。Argon2i 抗侧信道最强但抗 GPU 最弱，Argon2d 抗 GPU 最强但更容易被侧信道利用。
内存和迭代次数哪个更重要？
优先加内存。Argon2 的「内存硬」特性意味着攻击者想并行跑很多次猜测就必须准备同样多的内存，这会直接推高成本；迭代次数主要线性增加时间。工具里会把内存向下取整到「4 × 并行度」的整数倍（这是规范要求的分段方式），结果区会显示实际生效的内存。
盐要多长？可以复用吗？
每个密码一条独立随机盐，至少 16 字节（这里生成按钮给的就是 16 字节）。盐不需要保密，它存在 PHC 字符串里，作用是让相同密码得到不同摘要、并让攻击者无法用一张彩虹表覆盖所有用户。只有对照测试向量或复算别人的哈希时才手动填固定盐。
关键词：argon2argon2idpassword hashphc stringkey derivationblake2bArgon2 哈希密码哈希口令哈希内存硬函数密钥派生RFC 9106