1. 课程导入与ML-KEM概述
ML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism）是NIST后量子密码标准化进程中，于2024年正式发布的首个密钥封装标准，标准编号为FIPS 203。它的算法基础来自CRYSTALS-Kyber，属于基于模格上带误差学习问题（MLWE）构造的密钥封装机制。对开发者而言，理解ML-KEM不能只停留在"抗量子"这一标签上，而要弄清楚它在标准体系中的位置、封装与解封装的数据流，以及一条从算法实现到合规验证的完整工程路线。本课程将围绕这三条主线展开，共30节，最终目标是让读者能够独立完成一个可测试、可验证的ML-KEM实现。
一、为什么需要ML-KEM：从RSA/ECC的威胁说起
当前互联网广泛使用的RSA与椭圆曲线密钥交换，其安全性依赖于大整数分解和离散对数问题的计算困难性。Shor算法在理论上证明，具备足够规模量子比特的量子计算机可以在多项式时间内解决这两类问题。这意味着，一旦实用化量子计算机出现，现有公钥基础设施中的密钥交换环节将整体失效。更现实的风险是"先存储、后解密"攻击：攻击者今天截获并保存密文，等量子计算能力成熟后再解密。因此，密钥交换算法的迁移必须提前于量子计算机的实际出现。
ML-KEM正是为替代RSA-KEM和ECDH类密钥交换而设计的。它不直接加密业务数据，而是让通信双方协商出一个共享密钥，再由该密钥驱动AES-GCM或ChaCha20-Poly1305等对称算法加密实际数据。这种"KEM+对称加密"的组合，是后量子迁移中最常见的混合模式基础。
二、ML-KEM在PQC标准中的定位
NIST后量子标准化项目经过三轮筛选，最终确定了以格密码为主的技术路线。目前已发布和即将发布的核心标准包括：FIPS 203（ML-KEM，密钥封装）、FIPS 204（ML-DSA，数字签名）、FIPS 205（SLH-DSA，基于哈希的签名）。三者分工明确：ML-KEM负责密钥 establishment，ML-DSA负责身份认证与签名，SLH-DSA作为保守备选提供基于哈希的签名方案。
ML-KEM提供三个参数集：ML-KEM-512、ML-KEM-768、ML-KEM-1024，分别对应NIST安全等级1、3、5。其中ML-KEM-768是当前TLS 1.3混合密钥交换部署中最常用的配置。三个参数集共享同一套算法结构，差异在于模数q=3329下的多项式维度k（分别为2、3、4）以及相应的密钥和密文长度。这种"一套结构、多组参数"的设计，使得实现代码可以复用，仅通过编译期参数切换即可支持不同安全等级。
三、密钥封装机制的基本流程
KEM与传统的公钥加密在接口语义上有本质区别。公钥加密是"用公钥加密一段明文"，而KEM是"用公钥封装出一个共享密钥和一段密文"，接收方用私钥解封装恢复共享密钥。ML-KEM的内部流程可以概括为三个算法：KeyGen、Encaps、Decaps。
KeyGen生成公私钥对（ek, dk）。Encaps由发送方执行，输入接收方公钥ek，内部生成随机种子m，通过K-PKE加密得到密文c，同时用哈希函数从m和c派生出共享密钥K，输出（c, K）。Decaps由接收方执行，输入私钥dk和密文c，先解密得到m'，再重新加密并比对密文，最后通过哈希派生共享密钥。这里的"重新加密比对"是ML-KEM实现CCA安全的关键步骤，称为密文校验或隐式拒绝（implicit rejection）。如果比对失败，Decaps不会报错，而是输出一个由伪随机函数生成的替代密钥，从而避免攻击者通过错误响应获取信息。
四、开发与验证的整体路线图
本课程的工程路线分为四个阶段，每个阶段都有明确的交付物和验证手段。
第一阶段：算法理解与参考实现。以FIPS 203规范为唯一依据，逐条实现NTT变换、多项式乘法、压缩与解压缩、编码与解码等基础组件。这一阶段的关键不是追求性能，而是保证与规范逐比特一致。建议用Python或C语言编写参考版本，并用NIST提供的KAT（Known Answer Test）向量做逐项比对。KAT文件包含固定随机种子下的密钥、密文和共享密钥，任何一位不一致都说明实现有偏差。
第二阶段：常数时间与侧信道防护。ML-KEM的解密和密文比对环节涉及秘密数据，必须避免数据相关的分支和内存访问模式。具体做法包括：使用条件选择（conditional select）替代if-else，使用掩码（mask）实现压缩解压缩，确保NTT的蝶形运算不依赖秘密索引。这一阶段的验证手段是时序测量和缓存访问模式分析，通常借助dudect等统计工具判断是否存在可观测的时间差异。
第三阶段：接口集成与混合模式。将ML-KEM封装为符合应用需求的API，并与X25519等传统算法组合成混合KEM。混合模式的核心是密钥组合函数，通常采用"拼接后哈希"的方式：K_hybrid = H(K_pq ‖ K_classic)。这一阶段需要验证的是接口契约、错误处理和密钥生命周期管理，而不是算法本身。
第四阶段：合规验证与测试报告。对照FIPS 203的算法一致性要求，整理KAT通过率、边界条件测试、负向测试（篡改密文、错误私钥）和侧信道评估结果。对于需要进入产品环境的实现，还应关注ACVP（Automated Cryptographic Validation Protocol）测试向量格式，提前准备可自动化的测试脚本。
需要特别强调的是，ML-KEM的实现正确性不能靠"跑通一次"来判断。由于算法内部大量使用模运算、位压缩和哈希派生，一个细微的字节序错误或模数约简偏差，可能导致KAT在大多数向量上通过、却在特定输入下失败。因此，本课程后续每一节都会围绕"可观察的中间量"组织内容：NTT的输出、压缩前后的系数范围、哈希输入的拼接顺序，都是调试时需要盯住的关键点。
最后给出本节需要建立的整体认知：ML-KEM不是一个孤立的加密函数，而是一套包含密钥生成、封装、解封装、密文校验和隐式拒绝的完整协议组件。开发者的任务，是把这套规范转化为常数时间、可测试、可集成的代码；验证者的任务，是用KAT、负向测试和侧信道评估证明它确实按规范工作。接下来的章节将沿着这条路线，从模运算和NTT开始，逐步推进到完整的封装实现与验证报告。