题记与说明
本文由两份章节研究综合而成：纵轴（历时发展史，1949–2026）与横轴（2026-10-31 时间截面的横向对比）。章节原文见output/reports/parts/2026-10-31-加密与密钥管理-vertical.md与output/reports/parts/2026-10-31-加密与密钥管理入门-horizontal.md。综合时已消除两章重复（后量子标准、SHA-1 破灭、Sigstore、age、NIST IR 8547 等在两章均有出现的素材，按"史实在纵轴、现状对比在横轴"归位），并核实了细节口径（如 Chrome 启用的 Kyber 草案组与标准化后的 X25519MLKEM768 之别、FIPS 140-2/140-3 的时间差、SM4 的 GM/T 与 GB/T 双层标准号）。成文日期：2026-10-31。
final 修订说明（2026-10-31，按独立审读意见逐条处理，正文未被质疑的内容原样保留）：
① TL;DR 与纵轴洞察 1 的"15–25 年"统一为"定标 → 退场/终结"口径，三个年数分别标注端点（被替换/被实际利用/被实际碰撞），洞察 1 加口径提示；
② 修正"此事件的后半段见横轴 3.1"为"见横轴 2.6 要点"；全文交叉引用统一为"纵轴/横轴 + 节号"写法（"本文二.2"→"横轴 2.2"，"纵轴洞察 N"→"纵轴 1.7 的洞察 N"）；
③ TL;DR 后新增"概念坐标与名词速览"一节（四原语分工坐标系前移 + 术语速查），正文首次出现的 AEAD/nonce/信封加密/KDF/XOF 补一句话定义；
④ 2.6 对比表补 Bitwarden 行（部署形态/许可/动态秘密/定价，官方页面核实），与正文两处 Bitwarden 推荐对齐；
⑤ 3.4 核心建议改写为具体指向：已定稿的 ML-KEM/ML-DSA 即刻排期、"4 年合规窗口"与 2030 弃用硬线显式挂钩、未定稿的 FN-DSA（FIPS 206）不必等但走混合路线；
⑥ 3.1 论题改为"至少两代、至多三代"，对称位单独说明例外；crypto-agility 全文统一译为"算法敏捷性"（首次出现注英文，见纵轴洞察 5）；
⑦ 来源卫生：DSA"内嵌追踪器"说法改写为有据的 1991 年 512 位密钥争议并补来源；AKeyless"2025 年获 FedRAMP Class D"未获证实，删除；"IBM 收购 HashiCorp"补官方公告来源；参考来源占位符 URL 替换；上述处理全部纳入文末诚实声明；
⑧ 新增 3.6"常见追问与下一步"：作答 NIST 时间表为何非联邦系统也要跟进、"密码清单"怎么做、X25519MLKEM768 握手开销的实际影响、Argon2id 参数与 SOPS+age 最小上手；TL;DR 与纵轴洞察 5 补回"美国联邦系统"限定。
TL;DR
密码学 77 年的历史可以压缩成一句话：算法会老，密钥会漏，唯有人会犯错。纵轴显示，一个算法从定标到退场/终结约需 15–25 年（DES 24 年——被 AES 替换；MD5 16 年——Rogue CA 实际利用；SHA-1 22 年——SHAttered 实际碰撞），而全网迁移还要再花 10 年以上——现在轮到 RSA/ECC（按 NIST IR 8547，美国联邦系统 2030 年后弃用、2035 年后禁用）。在 2026 年 10 月的时间截面上，每个密码学位置都站着两到三代方案：AES-256-GCM/ChaCha20、X25519/Ed25519、SHA-256 是现役默认；ML-KEM/ML-DSA 混合模式已进入主流浏览器与 SSH；MD5/SHA-1 只剩遗产价值。密钥管理的"主语"则从个人（PGP）迁移到机构（PKI/HSM）、云（KMS）、代码流水线（Vault/SOPS），最终到身份本身（Sigstore keyless，不再持有长期私钥）。给实践者的结论：新系统用现代默认组合，能短命的密钥就不做长期密钥，并把"换算法"设计成改配置而不是重写系统。
概念坐标与名词速览
四个原语，各管一件事——这是横轴所有对比表的公共坐标系，后文所有表格都建立在这张图上：
| 原语 | 干什么 | 现役默认（2026） |
|---|---|---|
| 对称加密 | 藏数据：同一把密钥既加密又解密，快，适合大量数据 | AES-256-GCM、ChaCha20-Poly1305 |
| 非对称加密/密钥交换 | 发钥匙：公钥可以公开、私钥自己留，解决"对称密钥怎么安全送到对方手里" | X25519（后量子补位：ML-KEM） |
| 哈希 | 验完整：给数据算出指纹，验证数据没被篡改；单向、无密钥 | SHA-256 |
| 数字签名 | 认身份：用私钥对数据盖章，任何持公钥者可验证来源并防抵赖 | Ed25519（后量子补位：ML-DSA） |
先记住这个分工直觉：对称加密管"藏数据"、非对称管"发钥匙"、哈希管"验完整"、签名管"认身份"。正文首次出现的关键术语不再展开解释，速查如下（详见各自章节）：
| 术语 | 一句话解释 |
|---|---|
| AEAD | 认证加密：一次运算同时完成"加密"与"完整性校验"，是当前对称加密的标准形态 |
| nonce | 一次性编号：AEAD 每次加密必须使用不同的 nonce，重用会同时葬送保密性与可认证性 |
| 信封加密 | 两层加密：数据先由随机"数据密钥"加密，数据密钥再交给 KMS 主密钥加密，与密文一起存放 |
| KMS | 密钥管理服务：托管密钥的创建、存储、轮换与审计的云服务（AWS KMS、Azure Key Vault、GCP KMS） |
| KDF | 密钥派生函数：从主密钥或口令按规则派生子密钥（如 HKDF、Argon2id） |
| XOF | 可扩展输出函数：输出长度可按需设定的哈希变体（如 SHA-3 的 SHAKE、BLAKE3） |
| KEM | 密钥封装机制：用对方公钥"封装"出一份共享密钥的公钥原语，比通用公钥加密更贴合密钥交换场景 |
| 混合密钥交换 | 经典 + 后量子两组算法同时运行（X25519 + ML-KEM），任一被攻破仍有另一组兜底 |
| 口令哈希 | 慢哈希（Argon2id 等）：专为"人记的密码"设计，与 SHA-256 这类快哈希是两道题 |
| 动态秘密 | 用时现签、短 TTL、到期自动失效的临时凭据，让密钥"天然短命" |
| keyless 签名 | 用 OIDC 身份换短时证书来签名（Sigstore），根本不持有长期私钥 |
| 算法敏捷性（crypto-agility） | 把"用哪个算法"做成可配置项——换算法是改配置，不是重写系统 |
一、纵轴：发展脉络（1949–2026）
1.1 前史与理论奠基（1949–1975）：从手艺到科学
这一阶段没有"标准"与"产品"，只有两件事：理论化与垄断化。
- 1949 年，Claude Shannon 发表《Communication Theory of Secrecy Systems》（Bell System Technical Journal），第一次用信息论严格定义保密系统的安全性，把密码学从工匠手艺变成可定量分析的科学（背景知识，参见 Wikipedia 条目）。
- 冷战之下，密码学被政府机构垄断。英国 GCHQ 的 James Ellis 早在 1969 年就构想了"非秘密加密"（公钥加密的思想雏形）；1973 年 Clifford Cocks 独立提出本质上等同 RSA 的方案；1974 年 Malcolm Williamson 提出等同 Diffie-Hellman 的密钥交换。GCHQ 认为这些构想"没有工程价值"全部封存，直到 1997 年 12 月才解密公开（NSA 人物志、IEEE Milestone）。这段公案的启示是：封闭体系即使先发明了正确的数学，也可能错失它的价值。
- 同期，IBM 的 Horst Feistel 团队设计出 Lucifer 分组密码（Feistel 结构的来源），为 DES 铺路。
驱动因素：军备竞赛与通信保密需求。正因体系封闭，学术界与工业界无标准可用，为 70 年代的"密码学民主化"埋下伏笔。
1.2 公钥革命与商用标准诞生（1976–1990）
- 1976 年 11 月，Diffie 与 Hellman 发表《New Directions in Cryptography》，公开提出公钥密码与密钥交换思想，一举解决困扰千年的"密钥分发"问题（论文 PDF（斯坦福）、IEEE Xplore）。
- 1977 年，MIT 的 Rivest、Shamir、Adleman 提出 RSA，1978 年发表于 CACM。论文题目《A Method for Obtaining Digital Signatures and Public-Key Cryptosystems》本身就是一个重要事实：数字签名与非对称加密是一体两面、同时诞生的。RSA 于 1983 年获美国专利，2000 年 9 月到期。
- 1977 年 1 月 15 日，美国国家标准局（NBS）发布 FIPS 46，DES 成为联邦标准：64 位分组、56 位有效密钥，由 IBM Lucifer 改造而来，NSA 参与修改了 S 盒并缩短了密钥长度。56 位密钥从第一天起就遭 Diffie 与 Hellman 等人公开质疑（背景知识，参见 Wikipedia: DES）。
- 1985 年，Koblitz 与 Miller 分别提出椭圆曲线密码（ECC）；ElGamal 提出基于离散对数的加密与签名方案（ElGamal 签名是 DSA 的直系祖先）。
- 1988 年，X.509 随 X.500 目录服务发布，日后成为 PKI 与 TLS 证书体系的根基。
驱动因素：计算机进入企业与个人，跨机构通信需要互操作标准；美国出口管制（ITAR 把加密软件当军火）反而刺激了民间密码学社群的对抗式成长。
1.3 互联网商业化与"密码战争"（1991–2000）
- 1991 年，Phil Zimmermann 发布 PGP 1.0，让普通人第一次能在邮件里用上 RSA；1993–1996 年他因"军火未经许可出口"遭美国政府刑事调查，1996 年 1 月撤案。这场官司与 Clipper 芯片之争史称 90 年代"密码战争"（Zimmermann 文集）。PGP 随后标准化为 OpenPGP（RFC 2440（1998），后为 RFC 4880（2007））。
- 哈希与认证原语成型：MD5（RFC 1321，1992）、SHA-0（FIPS 180，1993）→ SHA-1（FIPS 180-1，1995）、HMAC（RFC 2104，1997）。NSA 主导设计的 DSA 在 1991 年公布时，因初始模数仅 512 位、被质疑"弱到可能便于政府解密"而遭业界广泛批评，方案遂被撤回修订（密钥上限放宽至 1024 位），1994 年定稿为 FIPS 186（NIST 1994 年公告、EPIC 档案）。
- 政府信任危机：1993 年克林顿政府推出 Clipper 芯片与密钥托管（key escrow），因隐私团体与业界强烈反对而失败，1996 年放弃——"后门合法化"第一次大规模尝试以失败告终。
- 浏览器与电商带来 TLS：Netscape 的 SSL 2.0（1995）、SSL 3.0（1996）；1999 年 IETF 接管并标准化为 TLS 1.0（RFC 2246）。SSLeay（1995）于 1998 年 fork 为 OpenSSL，成为此后二十年互联网加密的事实底座。
- DES 走向终结：1998 年 7 月，EFF 用约 25 万美元打造 Deep Crack 机器，56 小时暴力破解一个 DES 密钥，证明 56 位密钥在硬件进步面前不设防（Wikipedia: EFF Deep Crack）。NIST 遂于 1997 年 1 月启动 AES 全球公开竞赛：15 个候选（1998），5 强（MARS、RC6、Rijndael、Serpent、Twofish，1999）。
1.4 AES 时代与哈希危机（2001–2012）
- 2000 年 10 月 2 日 NIST 宣布比利时 Daemen & Rijmen 的 Rijndael 当选 AES（CSRC: AES Development）；2001 年 11 月 26 日 FIPS 197 正式发布（FIPS 197）。AES-128/192/256 至今仍是全球对称加密的默认选项。这也是一次范式转变：算法设计与评审由公开国际竞赛完成，不再由政府暗箱操作——而且胜出的是欧洲团队。
- 2002 年 FIPS 180-2 定型 SHA-256/384/512，SHA-2 家族至今仍是签名的默认哈希。
- 哈希危机（本阶段最大剧情）：
- 2004 年 8 月，山东大学王小云、于红波团队在 CRYPTO 2004 rump session 宣布攻破 MD5（连带 MD4、RIPEMD、HAVAL）；正式论文《How to Break MD5 and Other Hash Functions》发表于 EUROCRYPT 2005（构造碰撞约 2^37 代价）。
- 2005 年 2 月，该团队公布对 SHA-1 的理论攻击（约 2^69，后修正至 ~2^63），Bruce Schneier 当即写下著名的《SHA-1 Broken》（schneier.com）。
- 2008 年 12 月，Sotirov、Stevens、Appelbaum、Lenstra、de Weger 等人利用 MD5 选择前缀碰撞，用约 200 台 PlayStation 3 伪造出一张被所有主流浏览器信任的 Rogue CA 证书（攻击入口是 RapidSSL 一张 $253 的即时签发证书），等于当众处决了 MD5 在证书体系中的残余生命（参见 事后技术复盘）。
- 2012 年 10 月 2 日，NIST 宣布 Keccak 当选 SHA-3，2015 年 8 月发布 FIPS 202——哈希标准第一次完全由公开竞赛产出的非美国政府机构算法胜出。
- PKI 生态事故倒逼透明化：2011 年荷兰 CA 公司 DigiNotar 被入侵并签发假 Google 证书（伊朗用户遭中间人攻击），公司随即破产；2013 年 Certificate Transparency（RFC 6962）发布，Chrome 逐步强制所有新证书进公共日志。
- 曲线民主化：Daniel J. Bernstein 的 Curve25519（2006）与 Ed25519（2011）以"固定安全参数、免参数操纵疑虑、快且免侧信道"成为新默认，分别标准化为 RFC 7748（2016）与 RFC 8032（2017），此后 SSH、TLS、Signal、age 全面跟进。
1.5 云与 DevOps 的密钥管理工程化（2013–2018）
密码原语至此已足够强，但"密钥放哪儿、怎么轮换、谁持有"成了新瓶颈——本阶段主线是工程化、服务化与规模化。
- 2013 年斯诺登事件曝光 NSA 对加密流量的系统性干预，直接推动"全站 HTTPS"浪潮与对弱参数、可疑参数的不信任。
- 2014 年 4 月 Heartbleed（CVE-2014-0160）：OpenSSL 心跳扩展漏洞让任何人都可能远程读取服务器内存——包括 TLS 私钥。全球被迫大规模轮换密钥与证书，"手动轮换"的痛苦暴露无遗。救赎紧随其后：ISRG 的 Let's Encrypt 于 2015 年 9 月 14 日签发第一张公开信任的免费证书，其 ACME 协议后标准化为 RFC 8555（2019）——证书轮换从此免费且全自动。
- 密钥管理服务化（KMS）：2014 年 11 月 12 日 AWS 发布 KMS，把密钥的创建、存储、轮换、审计变成云 API（AWS Blog）；2015 年 6 月 Azure Key Vault 商用；2017 年 1 月 Google Cloud KMS 发布——三大云补齐"托管密钥 + 信封加密"模式（信封加密：数据用随机生成的"数据密钥"加密，数据密钥再用 KMS 主密钥加密后与密文一起存放，见文首名词速览）。标准侧：OASIS KMIP 1.0 于 2010 年 10 月成为标准，试图统一企业级密钥管理互操作协议；FIPS 140-2（2001 年起）长期充当 HSM 与密码模块的采购门槛。
- Secret 管理独立成门类：
- 2015 年 4 月 HashiCorp 发布 Vault（动态密钥、租约、撤销，项目解读），2018 年 10 月 Vault 1.0；2018 年 4 月 AWS Secrets Manager 推出，主打数据库凭据自动轮换。2023 年 HashiCorp 将 Vault 改为 BSL 许可后，社区在 Linux 基金会下 fork 出 OpenBao（此事件的后半段见横轴 2.6 要点）。
- Kubernetes 生态：K8s 自带 Secret 对象（2015）仅是 base64 编码，催生了 Mozilla SOPS（2015，只加密值、保留键可 diff 的 GitOps 加密方案，2023 年捐入 CNCF，getsops/sops）、Bitnami Sealed Secrets（2017，非对称"只写"密文进 Git，bitnami-labs/sealed-secrets）与 External Secrets Operator（CNCF 孵化，external-secrets.io）——"密钥进 Git"与"密钥出 Git"两条路线就此成型。
- 硬件端：FIDO U2F（2014）、WebAuthn/FIDO2（W3C 推荐标准，2019）把"密钥不出硬件"带给普通用户。
- 泄漏事故反复证明人肉管理不可行：2016 年 Uber 因工程师把云存储凭据提交进 GitHub 仓库导致 5700 万用户数据泄露（2017 年才披露）；2019 年丰田一个访问密钥在 GitHub 上挂了近五年。CI/CD 与代码托管成为 Secret 泄漏的头号入口。
1.6 后量子迁移与供应链信任（2019–2026）
- 新工具替代旧包袱：libsodium（2013）把"正确使用密码学"封装成防误用 API；Filippo Valsorda 的 age（2019 年底 beta，2021 年秋 v1.0.0，X25519 + ChaCha20-Poly1305，FiloSottile/age）取代 GPG 成为文件加密的新默认。
- 哈希的故事收尾：2017 年 2 月 23 日，Google 与 CWI 公布 SHAttered——首个完整 SHA-1 实际碰撞（两份内容不同、SHA-1 相同的 PDF，约 2^63.1，比暴力生日攻击快 10 万倍，Google Security Blog）；2020 年 1 月 Leurent & Peyrin 进一步实现选择前缀碰撞（"SHA-1 is a Shambles"）。2022 年 12 月 15 日 NIST 宣布 SHA-1 应于 2030 年前退役（SP 800-131A）。
- 供应链攻击倒逼签名自动化：2020 年 12 月 SolarWinds、2021 年 4 月 Codecov CI 凭据失窃之后，Sigstore 于 2021 年 3 月 9 日正式启动（Red Hat/Google/OpenSSF 支持），用 OIDC 身份 + 短生命周期证书（Fulcio）+ 透明日志（Rekor）实现无长期密钥（keyless）签名，把"保管私钥"从开发者职责中拿掉（Sigstore 官方博客）；SLSA 框架（2021）与 GitHub Artifact Attestations（2024）随后跟进。
- 后量子密码（PQC）从论文走进产品（工程现状的横向细节见横轴 2.2）：
- 2016 年 12 月 NIST 启动 PQC 全球征集；2022 年 7 月 5 日选定 Kyber、Dilithium、Falcon、SPHINCS+ 四算法（NIST 公告）；
- 2024 年 8 月首批最终标准发布：FIPS 203（ML-KEM）、FIPS 204（ML-DSA）、FIPS 205（SLH-DSA）（NIST 新闻、CSRC）；Falcon 对应的 FN-DSA（FIPS 206）仍在草案中，HQC 作为备选 KEM 于 2025 年 3 月入选；
- 工程落地早于标准定稿：OpenSSH 9.0（2022 年 4 月）默认启用 NTRU Prime + X25519 混合密钥交换，OpenSSH 10.0（2025 年 4 月）默认换为 ML-KEM 混合方案（OpenSSH PQC）；Chrome 124（2024 年 4 月）默认启用 X25519Kyber768 混合 TLS 握手（Chrome Platform Status），随后切换到标准化后的 X25519MLKEM768（部署面见横轴 2.2）；Signal PQXDH（2023 年 9 月）与 Apple iMessage PQ3（2024 年 2 月，Apple 安全博客）把 KEM 引入端到端消息协议。
- 迁移时间表：NIST IR 8547《Transition to Post-Quantum Cryptography Standards》（2024 年 11 月草案，2026 年定稿）明确 RSA、ECDSA、ECDH 等经典公钥算法 2030 年后 deprecated、2035 年后 disallowed（IR 8547 定稿 PDF）；"harvest now, decrypt later"（先存后解）威胁使长生命周期数据成为最紧迫的迁移对象。
- 模块认证换代：FIPS 140-2 的全部验证证书已于 2026 年 9 月 21 日转入历史名单，联邦采购合规全面转向 FIPS 140-3（对齐 ISO/IEC 19790）（CMVP: FIPS 140-3 Transition）。口径说明：下文横轴引用的 AWS KMS 官方博客成文于 2024 年，其中"FIPS 140-2 L3 HSM"是当时措辞；以 2026 年视角，新采购应认准 FIPS 140-3。
- 中国国密并行线：SM2（椭圆曲线公钥）、SM3（哈希）、SM4（分组密码）于 2016 年 8 月形成 GB/T 32918 / 32905 / 32907 国家标准（2017 年 3 月实施）；行业标准线为 GM/T 0002/0003/0004-2012（同一算法的国家标准与行业标准两层编号并存，横轴表格引用的是 GM/T 层）。2021 年 3 月 RFC 8998 将 SM 套件纳入 TLS 1.3；GmSSL、OpenSSL、铜锁（Tongsuo）等实现使国密算法可与国际算法在同一协议栈共存。
1.7 纵轴洞察：模式与规律
- 节奏规律：新原语 → 公开竞赛定标准 → 事故暴露短板 → 治理与自动化。DES（1977）→ AES（2001）相隔 24 年；MD5（1992）→ Rogue CA 处决（2008）16 年；SHA-1（1995）→ SHAttered（2017）22 年。算法"半衰期"约 15–25 年，而全网迁移往往还要再花 10 年以上——这正是 PQC 时间表（2030/2035）的制定逻辑。口径提示：上面三个年数用了三种不同端点（DES 数到被 AES 替换、MD5 数到被 Rogue CA 实际利用、SHA-1 数到被 SHAttered 实际碰撞），并非同一种"被攻破"；若只数到理论攻击出现，则 DES 21 年（Deep Crack，1998）、MD5 12 年（2004）、SHA-1 10 年（2005），半衰期会更短。
- 密钥管理的主语不断迁移：个人（PGP 时代自己保管私钥）→ 机构（PKI/HSM/KMIP）→ 云平台（KMS 托管 + 信封加密）→ 代码与流水线（Vault/SOPS/Sealed Secrets，生命周期全自动化）→ 身份即密钥（Sigstore keyless：根本不持有长期私钥）。每一次迁移都消掉一类"人犯错的环节"。
- 轮换从灾难词汇变成日常词汇：Heartbleed（2014）是分水岭；ACME、动态密钥、短生命周期证书让"轮换"不再是事故响应动作，而是每小时都在发生的常规操作。
- 信任模型在去中心化与可验证化之间演进：从信任单一 CA，到 CT 强制公开日志（2013 起），到 Sigstore 的透明日志 + OIDC 身份绑定——方向始终是"不必信任任何单一长期密钥，只验证可审计的证据"。
- 2026 年当下的位置：PQC 标准已定稿但全球迁移刚过半程；RSA-2048 / P-256 距美国联邦系统 2030 年 deprecated 硬线还有约 4 年合规寿命；FIPS 140-2 刚于上月（2026-09-21）谢幕；下一站是算法敏捷性（crypto-agility）——让"换算法"变成改配置而不是重写系统。
二、横轴：横向对比（时间截面 2026-10-31）
本课题横跨"算法原语"与"工程实践"两层，横向对比也分两层展开：算法层（对称加密、非对称加密/密钥交换、哈希、签名各类内部的主流候选）与工程层（密钥轮换策略与 Secret 管理工具）。统一对比维度：能力、性能、成本、生态、成熟度/合规、适用场景。时效敏感项（价格、版本）标注"以官方页面为准"。
2.1 对称加密：AES-GCM vs ChaCha20-Poly1305 vs SM4
| 维度 | AES-256-GCM | ChaCha20-Poly1305（含 XChaCha20） | SM4-GCM（国密） |
|---|---|---|---|
| 标准来源 | FIPS 197 / NIST SP 800-38D | RFC 8439（互联网标准） | GM/T 0002-2012（国标层为 GB/T 32907-2016） |
| 密钥长度 | 128/192/256 bit | 256 bit | 128 bit |
| 硬件加速 | AES-NI / ARMv8 几乎全面普及 | 无专用指令，依赖软件实现 | 无普遍硬件支持 |
| 无硬件时性能 | 查表实现有缓存侧信道风险 | 快、天然常量时间友好 | 软件实现与 AES 有差距 |
| nonce 重用容忍度 | 重用即灾难（GCM 认证可被破解） | 同样要求唯一，XChaCha20 降低误用风险 | 同为 AEAD，要求 nonce 唯一 |
| 生态位 | TLS 1.3 必备套件、企业/合规默认 | TLS 1.3 必备套件、移动/嵌入式首选 | 信创与国密合规体系（GM/T 0024 国密 SSL） |
| 适用场景 | 有 AES-NI 的服务器、桌面端 | 无 AES 指令的老旧设备、手机、IoT | 国内政务/金融合规 |
要点：三者都是当前公认安全的 AEAD 构造（AEAD：认证加密，一次运算同时完成加密与完整性校验；其每次加密所需的编号 nonce 必须唯一，重用即同时破坏保密与认证，术语详见文首名词速览），2025–2026 年社区共识没有实用攻击（对比讨论见 Netgate 论坛、aead_perf 基准）。性能是最核心的分水岭：带 AES-NI 的现代 CPU 上 AES-256-GCM 通常等于或快于 ChaCha20；无硬件加速的设备上 ChaCha20 明显更快且天然规避缓存时序侧信道（NordPass 对比）。这也是 TLS 库按客户端能力自动协商的原因：移动客户端常被优先给 ChaCha20，服务器互连给 AES-GCM。AES 生态最厚（FIPS 合规、全平台硬件指令），是"默认无脑选"；ChaCha20 零专利、代码简洁；SM4 的短板在性能与国际化生态而非安全设计，国内合规场景是强制/推荐选项（国密对比（CSDN）、国密生态演进（知乎）、SM4 高速实现）。
2.2 非对称加密与密钥交换：RSA vs ECDH/X25519 vs ML-KEM vs SM2
| 维度 | RSA-2048/3072 | ECDH (P-256) / X25519 | ML-KEM（FIPS 203） | SM2（国密） |
|---|---|---|---|---|
| 数学基础 | 大整数分解 | 椭圆曲线离散对数 | 格（Module-Lattice） | 256 位椭圆曲线 |
| 安全强度 | RSA-2048 ≈ 112-bit；3072 ≈ 128-bit | P-256/X25519 ≈ 128-bit | 抗经典+抗量子 | 对标 RSA-3072 级别 |
| 抗量子 | 否 | 否 | 是 | 否 |
| 密钥/密文开销 | 密钥 256B+，运算慢 | 32B 级密钥、运算快 | 密钥与密文 KB 级，运算快 | 密钥短、运算较 RSA 快 |
| 2030/2035 时间线 | 2030 后弃用、2035 后禁用（NIST IR 8547） | 同左 | 替代者 | 未在美国体系内，国密体系另有演进 |
| 适用场景 | 旧系统兼容、证书签发遗留 | 新系统默认密钥交换 | 逐步替换 ECDH，混合模式先行 | 国密 TLS、电子政务/金融 |
要点：
- 本年度最重要的横向事实：FIPS 203/204/205 已于 2024 年 8 月定稿（史实见纵轴 1.6，NIST 公告，NIST PQC 项目页）；NIST IR 8547 给出硬性时间线——2030 年后 RSA（所有密钥长度）、ECDSA、ECDH、DH 在联邦系统中弃用；2035 年后完全禁用（NIST IR 8547 原文）。"后量子"从研究话题变成了工程排期问题。
- 部署面已经成型：TLS 1.3 混合密钥交换 RFC 10024（PQ/T Hybrid Key Agreement）已于 2026 年 8 月成为 Proposed Standard，定义 X25519MLKEM768（代码点 4588）等三个混合组（IETF Datatracker）。按 Cloudflare PQC 支持文档：Chrome/Edge 131+、Firefox 132+、Safari 26+、OpenSSL 3.5.0+、Go 1.24+、Node.js 24.5+/22.20+（回移）、Java 27+（JEP 527）、Caddy 2.10+ 默认启用 X25519MLKEM768。口径说明：Chrome 最早在 124 版（2024-04）启用的是 Kyber 草案组 X25519Kyber768，标准定稿后才切换为 X25519MLKEM768——两章材料中的"Chrome 124"与"Chrome 131+"说的是这条演进线的两端，并不矛盾。综合现状：普通用户浏览网页的密钥交换已在相当大比例上是抗量子混合模式，驱动力是"先收割、后解密"。
- X25519 vs P-256：同为 128-bit 强度级，X25519 实现更难写错、无需验证公钥点、性能稳定，是新一代协议的事实默认；P-256 的价值在 FIPS 合规与既有生态。新代码一律 X25519。
- SM2：安全设计与国际主流 ECC 对等，密钥更短；国密合规体系中的标准选项，工程上可与 RSA/ECC 双栈部署。
2.3 哈希：SHA-2 / SHA-3 / BLAKE3 / SM3，以及一个最常见误区
MD5 与 SHA-1 已被碰撞攻击实用化（史实见纵轴），对抗场景一律禁用；NIST 已宣布 SHA-1 于 2030 年后不再允许用于数字签名。现役候选对比如下：
| 维度 | SHA-256（SHA-2） | SHA-3 | BLAKE3 | SM3（国密） |
|---|---|---|---|---|
| 摘要长度 | 256 bit | 256 bit | 256 bit（可扩展） | 256 bit |
| 当前状态 | 安全，事实标准 | 安全，FIPS 202 | 安全，非 NIST 标准 | 安全，GM/T 0004-2012 |
| 软件性能 | 快，有 SHA-NI 硬件加速 | 比 SHA-256 慢约 3 倍 | 软件最快（约 SHA-256 的 10 倍+，可并行） | 与 SHA-256 相当偏慢 |
| 标准化 | FIPS 180-4，无处不在 | FIPS 202（XOF：SHAKE） | 无 FIPS 合规 | 国密合规 |
| 附加能力 | — | 海绵结构、可变输出 | 内建 KDF/MAC/XOF/Merkle 树 | — |
| 适用场景 | 新项目默认 | 需要 FIPS 合规或不同数学族 | 高吞吐（内容寻址、去重） | 国密体系 |
要点：
- "更强"≠"更必要"：SHA-3 与 SHA-2 在当前攻击能力下并无实际安全差距，SHA-3 的价值在于不同的数学构造（海绵结构）作为保险，以及 SHAKE 可变输出；代价是慢约 3 倍、生态弱（哈希选型）。BLAKE3 在软件哈希中一骑绝尘且内建 KDF（密钥派生函数）/MAC/XOF（可扩展输出函数，即 SHAKE 那类可变长输出）/Merkle 树，但不是 FIPS 标准，合规项目不能用（术语详见文首名词速览）。
- 一个最常见误区（密码存储不是普通哈希）："用什么哈希"和"密码存数据库用什么"是两道题。后者属于口令哈希/慢哈希一族，2025 年 OWASP 口令存储速查表的推荐顺序：Argon2id（首选，最低参数 m=19 MiB、t=2、p=1）→ scrypt（Argon2id 不可用时，m=16 MiB、r=8、p=1）→ bcrypt（可用但 cost≥10，注意 72 字节截断）→ PBKDF2（仅在 FIPS-140 合规约束下，SHA-256 下 60 万次迭代）。普通 SHA-256 加盐从来不是合格的密码存储方案。
2.4 数字签名：RSA-PSS vs ECDSA vs Ed25519 vs ML-DSA，以及 Sigstore 的"无密钥"范式
| 维度 | RSA-PSS (2048/3072) | ECDSA (P-256) | Ed25519 | ML-DSA（FIPS 204） |
|---|---|---|---|---|
| 公钥/签名大小 | 256B+ / 256B+ | 32B / 64B | 32B / 64B | 1.3KB / 2.4KB（ML-DSA-65） |
| 签名速度 | 慢（验签快） | 快 | 最快（比 RSA-2048 快约 50 倍，确定性签名无 RNG 依赖） | 快 |
| 已知实现坑 | 填充模式易用错（必须 PSS/OAEP 而非 PKCS#1 v1.5） | nonce 复用/偏置即泄漏私钥，无效曲线攻击有真实事故 | 抗侧信道设计、无需高质量 RNG | 需防随机数风险 |
| 抗量子 | 否 | 否 | 否 | 是 |
| 生态位 | 遗留兼容、旧证书体系 | TLS 证书主流 | SSH/Git/新协议默认 | 新标准、逐步落地 |
要点：
- Ed25519 是 2026 年新系统的默认答案：约 128-bit 安全、32 字节公钥、64 字节签名、确定性签名，综合体验优于 RSA 与 ECDSA（Teleport 对比、Encryption Consulting）。
ssh-keygen -t ed25519早已是社区共识。ECDSA 只在 Ed25519 不可用但 ECC 可用时选；RSA（≥3072 位）只留给遗留兼容。 - 签名实践正从"管好长期密钥"转向"无密钥签名"：Sigstore 生态（sigstore.dev）用 Fulcio 签发绑定 OIDC 身份的短时证书 + Rekor 透明日志，让 CI 流水线用"身份"而非"存储的私钥"作为信任根——这从根上消灭了"私钥怎么保管、怎么轮换"这半个课题，是容器镜像/制品签名（cosign）的主流路线，也是与"密钥轮换"正交的另一种解法。
2.5 密钥轮换：策略与实现对比
| 方案 | 机制 | 典型周期 | 优点 | 代价/局限 |
|---|---|---|---|---|
| NIST SP 800-57 加密周期 | 按密钥类型/用途规定使用期限区间 | 数月~数年（风险评估决定） | 权威、体系化 | 只是框架，不给单一答案（NIST 密钥管理指南） |
| 云 KMS 定时轮换 | KMS 自动生成新密钥材料，旧材料仅保留解密 | AWS 默认 1 年；2024-04-12 起可配 90–2560 天并支持按需轮换 API | 零运维、对应用透明 | AWS 自己论证：密钥不出 HSM、每请求派生子密钥时，轮换的实际安全增益有限（AWS 官方博客） |
| 动态秘密（Dynamic Secrets） | 用时现签、短 TTL、到期自动失效 | 分钟~小时级（数据库凭据、云 IAM 临时令牌） | 把"轮换"变成"生命周期天然极短"，泄漏窗口趋近于零 | 需要中间件（Vault/OpenBao）与审计配套 |
| 无密钥/短时凭证（Sigstore、OIDC） | 每次操作签发短时证书/令牌 | 分钟级 | 无长期密钥可轮换 | 依赖在线基础设施（CA、日志） |
要点：
- 概念先行：NIST SP 800-57 Part 1 Rev.5 定义"加密周期"为"特定密钥被授权使用的时段"，区分"发起方使用期"与"接收方处理期"；它不规定统一周期，对称数据加密密钥通常约 2 年内，组织常按风险取 1 年甚至 90 天。
- 值得记取的反直觉结论：AWS KMS 对称密钥默认年轮换，2024 年 4 月起频率可配（价格同步调整，前两次轮换各加 $1/月，三次及以上降为 $3/月）。但 AWS 在同一篇博客里论证：对被 HSM 保护、且按请求 KDF 派生数据密钥的 KMS 密钥而言，加快轮换的边际安全收益不大——轮换的真正价值在"可疑时立即作废重造"的应急能力，而非例行公事的周期。
- 趋势判断：工程界正从"定时轮换静态密钥"滑向"短生命周期凭证"——数据库动态凭据、OIDC 联合身份、Sigstore keyless 都是这个方向的实例。心智模型：能短命的密钥就不做长期密钥；必须长期的，才谈轮换周期。
2.6 Secret 管理平台对比
| 方案 | 部署形态 | 许可证 | 动态秘密/轮换 | 定价（2026-10 查询，以官方页为准） | 适用场景 |
|---|---|---|---|---|---|
| HashiCorp Vault | 自托管/托管（HCP） | BSL 1.1（2023-08 起，非纯开源） | 强（数据库、PKI、云 IAM 动态凭据） | 开源版免费自托管；企业版按需报价 | 多云/混合、需要动态秘密与 PKI 的中大型组织 |
| OpenBao | 自托管 | MPL（纯开源），Linux 基金会治理 | 与 Vault 同源（fork 自 Vault） | 免费自托管 | 拒绝 BSL、要求开源治理的团队 |
| AWS Secrets Manager | 全托管 SaaS | 闭源 | Lambda 轮换、自动轮换 | $0.40/秘密/月 + $0.05/万次 API | 纯 AWS 技术栈 |
| Azure Key Vault | 全托管 SaaS | 闭源 | 密钥/证书/秘密三类资产，支持轮换策略 | 主要按操作计费（约 $0.03/万次） | Azure 栈；秘密+密钥+证书一站式 |
| GCP Secret Manager | 全托管 SaaS | 闭源 | 轮换调度与版本管理 | 按活跃版本计费（$0.06/版本/月）+ 访问量 | GCP 栈 |
| Infisical | 开源自托管 + 云 | MIT（核心） | 支持动态秘密 | Pro 约 $20/身份/月、Advanced 约 $40/身份/月（官方定价） | 开发者体验优先、中小团队 |
| Doppler | 纯 SaaS | 闭源 | 环境级同步 | 慷慨免费层 + 按席位 | 小团队快速起步 |
| 1Password Connect | 自托管 Connect + 云订阅 | 闭源服务 | 无动态秘密，偏人工保管 | Business 订阅（约 $7–8/人/月） | 已用 1Password 的团队做 Secret Automation |
| Bitwarden | 云 SaaS + 自托管（Enterprise 版含自托管） | 服务端主代码 AGPL-3.0，企业功能（SSO/SCIM 等）另有商业许可（仓库许可说明） | 无动态秘密；Bitwarden Secrets Manager 是静态机器秘密存储（项目化管理、机器账号、过期访问令牌） | 密码管理器 Teams $4/人/月、Enterprise $6/人/月（年付）；Secrets Manager Teams $6/人/月、Enterprise $12/人/月，超额机器账号 $1/个/月（官方定价、SM 产品页） | 个人/小团队"人的密码"；已用 Bitwarden 的团队顺带管机器秘密 |
| AKeyless | 纯企业 SaaS | 闭源 | 强（含 PAM、证书生命周期） | 报价制 | 企业级 Vault 替代 |
要点：
- 能力分界线是"动态秘密"：云原生三家本质是"加密的存储桶 + IAM"，而 Vault/OpenBao 能在请求时现签数据库账号、云 IAM 临时凭证、X.509 证书——与上节"短生命周期"趋势直接呼应（对比详见 Infisical 博客）。
- 成本结构差异巨大：AWS/GCP 按秘密数量与访问次数计费（秘密多了不便宜）；Azure 几乎只按操作计费；Vault/OpenBao 是基础设施+人力成本；Infisical/Doppler 按身份/席位，对小团队最友好（Bitwarden 的密码管理器亦按人/月计费且免费层覆盖个人）。
- 许可证与治理是 2023–2026 年这个领域最大的变量：HashiCorp 2023 年 8 月将 Vault 改为 BSL 引发社区反弹，Linux 基金会孵化出 OpenBao（MPL，与 OpenTofu 同门）；IBM 收购 HashiCorp（2024-04 宣布、2025-02-27 完成交割，IBM 公告）后，"开源治理是否延续"的疑虑使 OpenBao 成为不少团队的对冲选择。有社区报道称 NVIDIA 等采用 OpenBao、以及 2025 年出现过同一漏洞 OpenBao 先修复而 Vault 迟迟未修的报道（均来自搜索结果摘要，未直接核验原文）——选型时许可证与供应商风险应作为一级维度。
- 成熟度/合规：Vault 仍是合规生态（FIPS、企业支持）最厚的；云原生三家优势是 IAM 集成零成本与托管运维；新兴平台 SOC2 等已基本补齐，但企业级深度（HSM、审计合规矩阵）仍不及老牌方案。
2.7 GitOps/Kubernetes 场景与文件加密工具
GitOps 三件套对比：
| 维度 | SOPS（+age/KMS） | Sealed Secrets | External Secrets Operator | K8s 原生 Secret |
|---|---|---|---|---|
| 核心机制 | YAML 中值字段就地加密后提交 Git，可配 age/AWS KMS/GCP KMS 后端 | 用集群公钥加密成 SealedSecret CR，仅集群内控制器能解 | Git 里不存秘密，从外部仓库同步生成 K8s Secret | etcd 中的 base64（可配静态加密），本身不是加密 |
| Git 中是否可存 | 可（密文） | 可（密文） | 不可（只存引用） | 不应 |
| 密钥归属 | 你自己的 KMS/age 密钥 | 集群控制器私钥 | 外部 Secret 管理系统 | 集群自身 |
| 换集群/迁移 | 只要密钥在即可解密 | 需重新加密（绑定集群密钥） | 无影响 | — |
| 适用场景 | 已有云 KMS 或 age、想保持 Git 单一事实源 | 小团队最省心的 GitOps 加密 | 已有中心化 Vault/云 SM 的组织 | 从来不是完整答案，需配合加密与 RBAC |
社区的经典比喻："Sealed Secrets 像保险箱：秘密进去就出不来；SOPS 像灵活的保险柜：你决定谁有钥匙、何时开"（Minimal DevOps，2025-07）；ESO 不解决"Git 里怎么存"，而解决"怎么从中心仓库同步"（Cloudogu 综述）。三者可与 Vault/云 SM 叠加而非互斥。
文件加密：age vs GPG（SOPS 的后端选择）：
| 维度 | age | GPG |
|---|---|---|
| 设计哲学 | 只做加密，做好一件事 | 全功能：签名、Web of Trust、密钥环 |
| 密钥管理 | 无全局密钥环，密钥就是普通文件 | 密钥环/信任模型复杂，易用错 |
| 性能 | 实测约 GPG 的 3 倍快（对比基准） | 慢、历史包袱重 |
| 签名能力 | 无（加密专用，HN 讨论） | 有 |
| 生态 | SOPS 官方推荐优先 age 后端；有 YubiKey 插件 | OpenPGP 标准（RFC 4880），最通用 |
2.8 分场景选型速查
| 场景 | 推荐组合 |
|---|---|
| 新应用的算法默认 | AES-256-GCM（有硬件）/ XChaCha20（无硬件）+ X25519/Ed25519 + SHA-256（或 BLAKE3）+ Argon2id（密码存储） |
| 国内合规（信创/金融） | SM2/SM3/SM4 双栈 + 国密 TLS（GM/T 0024），保留国际算法兼容 |
| 个人/小团队 Secret 管理 | 1Password/Bitwarden（人的密码）+ Doppler 或 Infisical（机器的秘密） |
| 单一云技术栈 | 云原生 Secret Manager（AWS SM / Azure KV / GCP SM），轮换用托管能力 |
| 多云/混合/自建 IDC | Vault（合规企业版）或 OpenBao（开源治理）+ 动态秘密优先 |
| 纯 K8s GitOps | SOPS+age（灵活、可迁移）或 Sealed Secrets（最省心）；已有 Vault 则上 ESO |
| 抗量子迁移 | TLS 层：升级到支持 X25519MLKEM768 的组件（OpenSSL 3.5+/Go 1.24+ 等，多数已默认开启）；应用层：做算法敏捷性抽象；存档/长保密期数据优先混合加密 |
| 签名 | 新系统 Ed25519；制品/镜像签名考虑 Sigstore keyless（消灭长期私钥） |
| 密钥轮换 | 能短命就短命（动态秘密/OIDC/短时证书）；必须长期的才配轮换周期，并为"可疑时立即作废"留操作手册 |
三、交叉洞察：两轴结合说明了什么
单看纵轴，我们看到的是一部"算法不断被攻破、又不断被替换"的编年史；单看横轴，我们看到的是一张"每个位置都有三四个候选"的选型表。把两条轴交叉起来，才显出这个领域真正的结构。
3.1 选型即排队：每个"位置"上站着至少两代、至多三代方案
纵轴给出算法半衰期约 15–25 年；横轴的时间截面则显示，每一个密码学位置上都站着至少两代、至多三代方案。完整三代的是密钥交换位：RSA/DH（倒计时中）/X25519（现役）/X25519MLKEM768（新秀转正）；两代的是哈希位：MD5/SHA-1（退役）/SHA-2、SHA-3、BLAKE3（现役）；对称位是个例外——只有现役一代独大，因为对称算法目前普遍被认为可抵抗量子攻击，AES-GCM/ChaCha20 之后暂无"新秀代"在排队，这一位置近期不会出现换代压力。
两轴结合的推论是：横向选型表本质上是一张"排队表"——你今天选的现役方案，就是纵轴上某一章未来要写的"被替换故事"的主角。这不是悲观，而是排期依据：RSA-2048 距美国联邦系统 2030 年弃用硬线约 4 年，意味着任何新系统若绑定经典公钥算法，都应在架构里预留"算法可替换"的缝隙。这正是纵轴 1.7 的洞察 5 与横轴 2.8"算法敏捷性"条目的交汇点：把算法选择做成配置项（算法标识符、可插拔 KEM/签名接口），是横轴选型能兑现纵轴时间表的唯一办法。
3.2 横轴的工具光谱，是纵轴"主语迁移"的地层剖面
纵轴 1.7 的洞察 2 说密钥管理的"主语"从个人→机构→云→代码→身份不断迁移；横轴 2.6/2.7 的工具表其实正是这条迁移史的地层剖面——每一层工具都是纵轴某个时代的答案，至今并存：
- GPG/PGP 是"个人保管私钥"时代的活化石（age 是它的现代简化版，但信任模型相同：你自己持有密钥）；
- PKI/HSM/KMIP 是"机构持有"时代的遗产，今天仍活在证书体系与企业合规里；
- 云 KMS/Secrets Manager 是"云平台托管"时代的标准答案；
- Vault/OpenBao/SOPS/Sealed Secrets/ESO 是"代码与流水线"时代（DevOps/GitOps）的产物；
- Sigstore keyless 与 OIDC 短时凭证是"身份即密钥"时代的萌芽。
由此得出一个横轴表格给不出的判断：选择 Secret 管理工具，本质上不是比功能，而是选择"你把信任放在哪个主体上"。个人开发者选 1Password/Bitwarden 没有问题；强调不可抵赖与治理的机构可能需要 Vault 的审计与动态秘密；已经全面 GitOps 的小团队选 SOPS+age 就够。功能差异是表层的，信任模型差异才是根本的。
3.3 轮换语义的三次变化在 2026 年汇成一句话
纵轴 1.7 的洞察 3 记录了"轮换"从灾难词汇（Heartbleed 时代全球手动换证书）变成日常词汇（ACME 每小时自动续期）；横轴 2.5 则给出了当前的完整光谱：NIST 框架（按周期）→ 云 KMS 按钮（1 年可配 90 天起）→ 动态秘密（分钟级）→ keyless（无密钥可换）。
把两轴并排看，轮换的语义经历了三次变化：从"事故后的补救动作"，到"运维日历上的例行任务"，再到"让密钥天然短命、根本无需轮换"。而 AWS 那篇反直觉博客（横轴 2.5）恰好是这条演化线的理论总结：当密钥被 HSM 保护、且数据密钥按请求派生时，例行轮换的边际收益趋近于零，轮换的真正价值只剩下"可疑时立即作废"的应急能力。两轴结合的操作结论只有一句话：能短命就短命（动态秘密/短时证书/OIDC）；必须长期的才配轮换周期；无论哪一种，都要为"可疑时立即作废"写好操作手册——横轴 2.8 的最后一条选型速查就是这句话的工程化表达。
3.4 "事故 → 标准 → 自动化"三段式，是本领域最强的可预测模式
纵轴的每个阶段都重复同一个三段式：MD5 Rogue CA（事故）→ Certificate Transparency（标准）→ Chrome 强制公开日志（自动化）；Heartbleed（事故）→ ACME（标准）→ Let's Encrypt 全自动轮换（自动化）；SolarWinds/Codecov（事故）→ SLSA（框架）→ Sigstore keyless 签名（自动化）；斯诺登与量子威胁（警报）→ NIST PQC 竞赛（标准）→ 浏览器/SSH 默认启用混合密钥交换（自动化）。
对读者最有用的推论是时序规律：工程落地总是早于标准定稿（Chrome 124 启用 Kyber 草案组在 FIPS 203 定稿之前，OpenSSH 9.0 启用混合交换在标准发布之前），但标准定稿之前都用"混合模式"对冲不确定性（X25519 + ML-KEM 同时使用，任一被攻破仍有保护）。给实践者的建议因此是双向的：已定稿的 ML-KEM/ML-DSA（FIPS 203/204/205）不必再等，现在就排期——距美国联邦系统 2030 年弃用硬线只剩约 4 年合规窗口，存量 RSA/ECC 的替换要压在这 4 年内完成；仍在草案中的 FN-DSA（FIPS 206）等标准不必等它定稿，但落地时应走混合路线对冲不确定性（X25519 + ML-KEM 同时使用，任一被攻破仍有保护），也不要在标准定稿前就全量切换到裸新算法。这正是横轴 2.2 部署面数据（主流浏览器与运行时已默认开启 X25519MLKEM768）与纵轴 1.6 迁移时间表（2030/2035）能够同时成立的机制。
3.5 对用户的判断与建议
学习路径（入门者）：先理解四原语的分工——对称加密管"藏数据"、非对称管"发钥匙"、哈希管"验完整"、签名管"认身份"——这套坐标系已前移至文首"概念坐标与名词速览"，是横轴所有对比表的公共坐标系；然后学工程层：KMS 与 Secret 管理（纵轴 1.5 的历史能帮你理解每类工具为何长成那样）；最后跟踪 PQC 迁移与签名自动化两个前沿（纵轴 1.6）。
工程清单（实践者）：
- 新系统默认组合照抄横轴 2.8 第一行：AES-256-GCM/XChaCha20 + X25519/Ed25519 + SHA-256 + Argon2id（密码存储）；
- 盘点存量系统里的 RSA/ECDSA/MD5/SHA-1 使用点，建立"密码清单"（cryptographic inventory），为 2030 硬线排期（具体做法与工具见 3.6 问二）；
- 能短命的密钥不做长期密钥；CI/签名优先考虑 Sigstore keyless；数据库凭据优先动态秘密；
- Git 里的秘密用 SOPS+age 或 Sealed Secrets，K8s 原生 Secret 必须配合 etcd 静态加密与 RBAC（SOPS+age 最小上手见 3.6 问四）；
- 把算法选择抽象为可配置项（算法敏捷性），这是应对下一次"算法半衰期到期"的唯一廉价保险；
- 国内合规项目做国密/国际双栈，注意 SM 系列的 GM/T 与 GB/T 双层标准号对应关系。
两个不要：不要自己发明密码学构造（纵轴上所有悲剧都源于此，包括 NSA 自己缩短 DES 密钥的行为在 21 年后被 Deep Crack 处决）；不要把"轮换"当成万能药——AWS 的分析与 Uber/丰田的泄漏事故共同说明，绝大多数密钥事故是"人把密钥放错了地方"，而不是"密钥用得太久"。
3.6 常见追问与下一步
按上文逻辑推演，读者读完最容易追问的四件事，在此逐条作答；超出本文范围的，显式声明并给指向。
问一：NIST IR 8547 的 2030/2035 是美国联邦系统的时间表，非联邦、非美国的系统为什么要跟进？
先补上 TL;DR 与纵轴 1.7 的洞察 5 原先省略的限定：2030 年弃用/2035 年禁用的硬约束，只落在美国联邦信息系统上（横轴 2.2 与纵轴 1.6 均已注明）。非联邦系统跟进的三个理由：其一，事实标准来自供给侧——Chrome/Edge、Firefox、Safari、OpenSSL、Go、Java、OpenSSH 等全球共用组件已默认启用 X25519MLKEM768（横轴 2.2），无论在哪个法域，你的流量协议都会跟着组件默认值走，逆行者承担的是兼容与安全审查成本；其二，"先收割、后解密"不看法域（纵轴 1.6）——今天被存下的密文，量子算力成熟时是全局可解的，长保密期数据等不起自己辖区的时间表；其三，合规会外溢——为美国联邦系统供货或身处其供应链的供应商，会被合同与采购要求拉进这条时间线。所以真正的判断标准不是"是否美国系统"，而是数据的保密期是否长于迁移周期。各国/各行业监管的具体差异不在本文覆盖范围，指向：跟踪本国密码主管机构的 PQC 公告（如中国国家密码管理局，见参考来源）与所用组件的迁移文档。
问二：建立"密码清单"（cryptographic inventory）用什么工具、怎么做？
按四步走：
- 代码与依赖面：扫描自家代码与依赖中的密码 API 调用点——按算法名（RSA、ECDSA、MD5、SHA-1、DES 等）与各语言密码库 import 检索；
- 协议与配置面：枚举 TLS/SSH/JWT 的证书链、密码套件与签名算法配置，把"哪些服务还在用经典公钥算法"数清楚；
- 密钥面：从 KMS/HSM、内部 CA 与证书透明日志导出密钥与证书台账（谁持有、何时到期、保护什么）；
- 归一成"密码物料清单"（CBOM，Cryptography Bill of Materials）：CycloneDX 1.6（2024-04）起原生支持 CBOM，把算法、密钥长度、用途、保护对象结构化记录，IBM 等方提供配套扫描工具（如 CBOMkit）（CycloneDX CBOM、IBM/CBOM）。有了这份底账，2030 硬线的替换排期才有对象与优先级。
本文未逐一评测各扫描工具的能力边界，工具选型以各官方文档为准。
问三：混合握手 X25519MLKEM768 的"KB 级"开销，对 TLS 握手实际影响多大？
把数字拆开（部署分析、部署指南）：ML-KEM-768 的封装公钥 1184 字节、密文 1088 字节；X25519 两侧各 32 字节。合入同一混合组后，客户端 key share 从 32 字节涨到约 1216 字节、服务端回包约 1120 字节——整个握手净增约 2 KB，ClientHello 整体从约 300–500 字节涨到约 1300–1500 字节。对人类网页浏览，这个量级的传输与计算开销在现代带宽与 CPU 上基本无感；真正的坑在兼容性：超大 ClientHello 在个别企业中间件（防火墙、DPI 设备、负载均衡）上可能被静默丢弃或分片出错，QUIC 初始包也更容易触顶。结合横轴 2.2（主流客户端已默认开启），实践建议：服务端保留纯 X25519 组作为回退；IoT、高频短连接与极小 MTU 场景先实测再全量。
问四：Argon2id 参数在常用语言里怎么配？SOPS+age 最小上手长什么样？
参数基线沿用横轴 2.3 引用的 OWASP 口令存储速查表：Argon2id 最低 m=19 MiB（=19456 KiB）、t=2、p=1；通行经验是把单次哈希调到生产机上约 0.5–1 秒、随硬件上调，并把结果存成 PHC 格式字符串（自带算法与参数头），以便日后无损升级参数。
常用语言示例（按 OWASP 最低参数书写，生产建议上调 memory）：
# Python：argon2-cffi（其默认值 64 MiB / t=3 / p=4 已高于 OWASP 下限）
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=2, memory_cost=19456, parallelism=1) # memory 单位 KiB
h = ph.hash("password")
ph.verify(h, "password")// Go：golang.org/x/crypto/argon2（IDKey 即 Argon2id；盐与 PHC 编码需自理）
key := argon2.IDKey([]byte(password), salt, 2, 19456, 1, 32) // t, m(KiB), p, keyLen// Node：node-argon2
const argon2 = require("argon2");
await argon2.hash("password", {
type: argon2.argon2id, memoryCost: 19456, timeCost: 2, parallelism: 1, // memoryCost 单位 KiB
});（Python 绑定见 argon2-cffi 文档；Go 的 x/crypto 只提供裸 KDF 函数，盐生成与 PHC 编码需自行封装。）
SOPS+age 最小上手（命令整理自 getsops/sops 官方 README）：
# 1) 生成 age 密钥对（私钥文件妥善保管，绝不入 Git）
age-keygen -o key.txt # 输出 age1... 开头的公钥
export SOPS_AGE_RECIPIENTS=age1xxxxxxxx # 加密方：用公钥
# 解密方：export SOPS_AGE_KEY_FILE=key.txt（指向私钥文件）
# 2) 加密：值字段就地加密，键保留，Git 里可 diff
sops -e secrets.yaml > secrets.enc.yaml
# 3) 日常编辑与查看
sops secrets.enc.yaml # 解密进 $EDITOR 编辑，保存后自动重新加密
sops -d secrets.enc.yaml # 只读解密到 stdout
# 4) 把加密规则固化进 .sops.yaml（只含公钥，可安全入库）
cat > .sops.yaml <<'EOF'
creation_rules:
- path_regex: secrets/.*\.ya?ml$
age: age1xxxxxxxx
EOF两个易错点：加密用公钥（recipient）、解密用私钥文件（SOPS_AGE_KEY_FILE），别配反；CI/集群侧只需要私钥文件的最小读取权限。
四、参考来源
纵轴章节（vertical）核实来源：
- NIST CSRC: AES Development — https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/archived-crypto-projects/aes-development ；FIPS 197 — https://csrc.nist.gov/pubs/fips/197/final
- Diffie & Hellman, New Directions in Cryptography — https://ee.stanford.edu/~hellman/publications/24.pdf ；IEEE Xplore — https://ieeexplore.ieee.org/document/1055638
- NSA: Clifford Cocks, James Ellis, and Malcolm Williamson — https://www.nsa.gov/History/Cryptologic-History/Historical-Figures/Historical-Figures-View/Article/3006218/clifford-cocks-james-ellis-and-malcolm-williamson ；IEEE Milestone — https://ethw.org/Milestones:Invention_of_Public-key_Cryptography,_1969
- Phil Zimmermann 文集 — https://www.philzimmermann.com/EN/essays/index.html
- RFC 2246（TLS 1.0）/ RFC 8446（TLS 1.3）— https://www.rfc-editor.org/info/rfc8446 ；RFC 1321（MD5）、RFC 2104（HMAC）、RFC 2440/4880（OpenPGP）、RFC 6962（CT）、RFC 7748/8032（X25519/EdDSA）、RFC 8555（ACME）、RFC 8998（国密 TLS 1.3）— 原文均可在 rfc-editor.org 按编号取用（如 https://www.rfc-editor.org/info/rfc8998 ）
- Schneier, SHA-1 Broken（2005）— https://www.schneier.com/blog/archives/2005/02/sha1_broken.html ；MD5 Rogue CA 复盘 — https://cendyne.dev/posts/2023-09-01-spoofing-certificates-with-md5-collisions.html
- SHAttered 公告（Google）— https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
- NIST 首批 PQC 算法选定（2022-07）— https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms ；NIST 首批 PQC 标准发布（2024-08）— https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards ；CSRC — https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved
- NIST IR 8547 定稿 — https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8547.pdf ；SHA-1 退役计划（SP 800-131A）— https://csrc.nist.gov/pubs/sp/800/131/a/r2/ipd
- AWS KMS 发布公告（2014-11-12）— https://aws.amazon.com/blogs/aws/new-key-management-service ；HashiCorp Vault 解读 — https://cybr.com/explained-series/what-is-hashicorp-vault-and-why-should-you-know-about-it
- SOPS — https://github.com/getsops/sops ；Sealed Secrets — https://github.com/bitnami-labs/sealed-secrets ；External Secrets Operator — https://external-secrets.io ；age — https://github.com/FiloSottile/age
- Sigstore 启动公告 — https://blog.sigstore.dev/whats-next-for-sigstore-1969e7321f75
- OpenSSH 后量子支持 — https://www.openssh.org/pq.html ；Chrome 124 混合密钥交换 — https://chromestatus.com/feature/5257822742249472 ；Apple iMessage PQ3 — https://security.apple.com/blog/imessage-pq3/
- FIPS 140-3 过渡 — https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-transition-effort
- Wikipedia: Communication Theory of Secrecy Systems — https://en.wikipedia.org/wiki/Communication_Theory_of_Secrecy_Systems ；Wikipedia: DES — https://en.wikipedia.org/wiki/Data_Encryption_Standard ；Wikipedia: EFF Deep Crack — https://en.wikipedia.org/wiki/EFF_Deep_Crack
- DSS/DSA 1991 年争议与 1994 年定稿（final 修订补）— https://www.nist.gov/news-events/news/1994/05/nist-announces-digital-signature-standard-computer-security ；https://archive.epic.org/crypto/dss/new_nist_nsa_revelations.html
横轴章节（horizontal）核实来源（标注"已直接抓取核验"的为章节作者在本会话抓取原文核验）：
- NIST 首批后量子标准公告（FIPS 203/204/205，已直接抓取核验）— https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
- Cloudflare PQC 支持文档（各浏览器/库默认启用版本，已直接抓取核验）— https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/
- AWS KMS 轮换官方博客（90–2560 天可配、按需轮换、价格调整，已直接抓取核验）— https://aws.amazon.com/blogs/security/the-curious-case-of-faster-aws-kms-symmetric-key-rotation/
- RFC 10024（PQ/T 混合密钥交换，2026-08 Proposed Standard，已直接抓取核验）— https://datatracker.ietf.org/doc/rfc10024/
- NIST IR 8547（2030 弃用/2035 禁用时间线）— https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8547.pdf ；NIST PQC 项目页 — https://csrc.nist.gov/projects/post-quantum-cryptography ；NIST 密钥管理指南 — https://csrc.nist.gov/projects/key-management/key-management-guidelines
- AES vs ChaCha20 — https://forum.netgate.com/topic/196605/ciphers-aes-256-gcm-vs-chacha20-poly1305 ；https://github.com/PandaZ3D/aead_perf ；https://nordpass.com/blog/xchacha20-encryption-vs-aes-256
- SSH/签名密钥对比 — https://goteleport.com/blog/comparing-ssh-keys ；https://www.encryptionconsulting.com/comparing-ssh-keys
- 哈希选型 — https://kerkour.com/fast-secure-hash-function-sha256-sha512-sha3-blake3 ；SHA-1 碰撞 — https://shattered.io/
- 口令哈希：OWASP Password Storage Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- Secret 平台对比与定价 — https://infisical.com/blog/aws-secrets-manager-vs-hashicorp-vault ；https://infisical.com/pricing ；https://www.doppler.com
- GitOps 三件套 — https://minimaldevops.com/sealed-secrets-vs-sops-which-should-you-use-to-manage-kubernetes-secrets-in-gitops-cc20a2f52cb3 ；https://platform.cloudogu.com/en/blog/gitops-kubernetes-secrets
- age vs GPG — https://gerowen.substack.com/p/age-vs-gpg-pgp-encryption ；https://github.com/FiloSottile/age/discussions/432 ；https://news.ycombinator.com/item?id=45825040
- Sigstore — https://www.sigstore.dev
- 国密对比 — https://blog.csdn.net/shadow2007881125/article/details/147049148 ；https://zhuanlan.zhihu.com/p/1953417284178646128 ；https://www.haitaichina.com/gxnmm/index.htm ；国家密码管理局 — https://www.oscca.gov.cn
final 修订新增来源（2026-10-31，本稿修订时检索/抓取）：
- IBM 完成 HashiCorp 收购（2024-04 宣布、2025-02-27 交割）— https://newsroom.ibm.com/2025-02-27-ibm-completes-acquisition-of-hashicorp,-creates-comprehensive,-end-to-end-hybrid-cloud-platform
- Bitwarden 定价 — https://bitwarden.com/pricing/ ；Bitwarden Secrets Manager — https://bitwarden.com/products/secrets-manager/ ；Bitwarden 服务端仓库与许可结构 — https://github.com/bitwarden/server
- X25519MLKEM768 握手开销（已直接抓取核验）— https://www.postquantumsecurity.org/publications/X25519+MLKEM768.html ；https://www.encryptionconsulting.com/x25519mlkem768-tls-deployment-guide ；IETF 混合密钥交换草案 — https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
- CycloneDX CBOM — https://cyclonedx.org/capabilities/cbom ；https://github.com/IBM/CBOM
- Argon2id 语言绑定 — https://argon2-cffi.readthedocs.io/en/stable/api.html ；SOPS 官方仓库（age 用法）— https://github.com/getsops/sops
沿袭两章的诚实声明：标注"未直接核验"的事实（OpenBao 采用方报道、Vault 修复时差报道）来自搜索结果摘要，仅作背景参考；两章作者已核验的事实，本稿未重新独立核验。final 修订（2026-10-31）新增内容的核验口径：已直接抓取核验——X25519MLKEM768 握手开销数字（postquantumsecurity.org）、Bitwarden 定价与 Secrets Manager 形态（bitwarden.com 两个页面）、Bitwarden 服务端许可结构（GitHub 仓库页）；经检索交叉确认、未直接抓取原文——IBM 收购 HashiCorp 于 2025-02-27 完成交割、DSS 1991 年 512 位争议与 1994 年定稿、CycloneDX 1.6 支持 CBOM、Argon2id 与 SOPS+age 的绑定用法及命令。原稿 AKeyless"2025 年获 FedRAMP Class D"未获证实（检索提示 FedRAMP 20x 的 Class D 分级并非 2025 年既有设计），已删除该说法，准确状态请以 FedRAMP Marketplace 为准；原稿 DSA"内嵌追踪器"说法查无出处，已改写为有据的 1991 年 512 位密钥争议史实并补来源。3.6 的代码示例为按官方文档整理的最小演示，未经生产环境验证。价格与版本数据为 2026-10-31 前后查询结果，以各官方页面实时数据为准。