2029 年大限将至！Go 前密码学掌门人更新“密码学正确答案”：所有非对称算法都得换
内容提要
后量子迁移共识截止2029年，仅剩三年。对称密码基本不变，256位密钥即可，Grover算法不构成威胁。非对称算法须全面更换：密钥交换用X25519+ML-KEM-768，签名用ML-DSA-44，加密用HPKE或age。密钥交换最紧迫，因“先存储后解密”攻击。TLS库推荐rustls、Go crypto/tls等，避免OpenSSL；备份用restic。建议用内存安全语言并让LLM审查代码。
延伸解读
为什么密钥交换必须最先迁移
文章指出，后量子迁移中最紧迫的是密钥交换，而非签名或加密。原因在于“先存储、后解密”攻击：攻击者可以现在截获并存储加密流量，等未来量子计算机可用时再解密。这意味着即使当前没有量子计算机，非PQ的密钥交换方案也已经构成现实风险。因此，TLS、SSH等协议应尽快启用X25519+ML-KEM-768等混合或纯PQ方案。
对称密码为何可以暂时不慌
与公钥密码不同，对称密码受量子计算的影响较小。文章解释，Grover算法虽然能加速暴力破解，但并未构成实质性威胁，256位密钥已足够安全。因此，AES、ChaCha20等对称算法及其密钥长度无需过度调整。开发者不必急于修改TLS库的默认密码套件，重点应放在非对称算法的替换上。
签名迁移的取舍与例外
文章推荐使用ML-DSA-44作为后量子签名方案，并建议避免混合签名或组合签名，因为其复杂度高且收益有限。同时，非对称签名应尽量少用，能用HMAC或随机会话令牌替代的就替换。一个例外是SSH密钥：OpenSSH 10.6选择了ssh-mldsa44-ed25519，作者认为这是错误，但偏离主流同样不可取。
工具选型与工程实践建议
在TLS库选择上，文章不推荐OpenSSL，而是推荐rustls、Go crypto/tls等内存安全实现，或BoringSSL、AWS-LC等。备份工具应从Tarsnap转向restic，因为restic完全使用对称密码，不受量子威胁影响。此外，建议使用内存安全语言，并利用LLM审查代码，以发现潜在漏洞。
Q&A
后量子迁移为什么必须在2029年前完成？
因为业界在2026年初形成共识，后量子迁移的截止时间是2029年，只剩三年时间。主要紧迫性来自“先存储、后解密”攻击，即攻击者现在存储加密流量，等量子计算机成熟后再解密。
对称密码需要换成后量子算法吗？
不需要。Grover算法实际上不构成威胁，对称密码基本不用慌。建议使用256位密钥即可，不必过度纠结，也不要强行修改TLS库的默认密码套件。
后量子时代密钥交换应该用什么算法？
推荐使用X25519+ML-KEM-768，并放在标准安全协议里。具体如TLS用X25519MLKEM768，SSH用mlkem768x25519-sha256，HPKE和age用MLKEM768-X25519。如果混合方案会导致在经典非PQ密钥交换上多停留哪怕一个月，就直接上纯ML-KEM-768。
后量子数字签名应该选择什么算法？
推荐直接使用ML-DSA-44。需要预哈希时用“external-μ（Mu）”签名，不用HashML-DSA。密钥只存32字节种子。避免混合签名或组合签名，也避开RSA、ECDSA、Ed25519等所有非PQ选项。
后量子迁移中TLS库和备份工具应该怎么选？
TLS库不推荐OpenSSL，推荐rustls、Go crypto/tls、BoringSSL、AWS-LC、s2n-tls。备份工具用restic代替Tarsnap，配一个足够长的随机密码，因为restic完全使用对称密码，不怕量子计算机。
今天就能开始的后量子迁移行动有哪些？
三件事：1. 检查TLS栈，确认启用了X25519MLKEM768（需要TLS 1.3），OpenSSL至少3.5；2. 盘点签名，能换成HMAC或随机令牌的先换掉，其余规划迁移到ML-DSA-44；3. 审计代码，用内存安全语言（如Rust、Go），再让最强的LLM审查一遍。
