1. 课程导入：后量子密码（PQC）背景、标准化进展（NIST）、硬件加速的必要性与挑战、课程目标与学习路径
量子计算正在从理论走向工程验证。2023年，IBM展示了1121量子比特的Condor处理器；2024年，Google的Willow芯片在量子纠错上取得里程碑式进展。尽管距离破解RSA-2048所需的数百万逻辑量子比特仍有距离，但“先收集、后解密”（Harvest Now, Decrypt Later）的攻击模式已经让长期敏感数据面临现实威胁。密码学正经历从经典公钥体制向抗量子体制的范式迁移，而这场迁移的落地瓶颈，恰恰在于硬件——尤其是FPGA与ASIC上的高性能实现。
1.1 量子威胁与PQC的必然性
1994年，Peter Shor提出的大数分解算法在理论上证明了量子计算机能够以多项式时间破解RSA和ECC。这意味着一旦大规模容错量子计算机问世，当前互联网所依赖的TLS/SSL、数字签名、密钥交换体系将全面失效。更紧迫的是，攻击者现在就可以截获并存储加密通信流量，等待未来量子计算机解密——这就是“先收集、后解密”策略。对于需要保密20年以上的数据（如医疗记录、政府文件、长期密钥），迁移到PQC已经不是可选项，而是必选项。
从密码学原理看，PQC算法所依赖的数学难题（格上的最短向量问题SVP、最近向量问题CVP、哈希函数原像抗性等）在经典和量子计算下均缺乏多项式时间求解算法。以NIST选定的ML-KEM（Kyber）为例，其安全性基于Module-LWE问题，密钥长度和密文开销远大于ECC，但算法结构规整，适合硬件并行化。
1.2 NIST标准化进展与算法选型
NIST于2016年启动后量子密码标准化项目，历经三轮筛选，于2024年8月正式发布三项标准：
| 标准编号 | 算法名称 | 类型 | 硬件关注点 |
|---|---|---|---|
| FIPS 203 | ML-KEM (Kyber) | 密钥封装机制 (KEM) | NTT变换、多项式乘法、CBD采样 |
| FIPS 204 | ML-DSA (Dilithium) | 数字签名 | NTT、拒绝采样、哈希链 |
| FIPS 205 | SLH-DSA (SPHINCS+) | 无状态哈希签名 | 大规模并行哈希、Merkle树 |
此外，FN-DSA（Falcon）作为基于NTRU格的高效签名方案，虽未进入最终标准，但在低带宽场景仍有重要应用。硬件设计者需要关注的是：ML-KEM和ML-DSA共享NTT核心运算，这意味着一个设计良好的NTT引擎可以同时服务两种算法，大幅降低硬件复用成本。
1.3 硬件加速的必要性与性能差距分析
软件实现PQC在通用CPU上已经可行，但性能差距显著。以ML-KEM-768为例，在2.0GHz的x86处理器上，密钥生成约需50μs，封装约需70μs，解封装约需90μs。对于TLS握手场景，这比传统ECDHE慢3-5倍。而在物联网边缘设备（如智能电表、车联网V2X模块）中，CPU主频往往只有200-500MHz，且没有硬件加速单元，软件实现可能消耗数百毫秒，完全无法满足实时性要求。
硬件加速的必要性体现在三个维度：
- 性能维度：FPGA实现ML-KEM-768的密钥生成可达到5-10μs，ASIC可进一步压缩至1-3μs，比软件快一个数量级以上。
- 功耗维度：ASIC在相同吞吐率下功耗仅为FPGA的1/5至1/10，适合电池供电设备。
- 安全维度：硬件隔离可以防止缓存侧信道攻击，且便于集成物理不可克隆函数（PUF）和真随机数发生器（TRNG）。
1.4 硬件加速的核心挑战
PQC硬件加速并非简单地将C代码翻译为RTL，而是面临以下系统性挑战：
- 算法复杂度跃升：ML-KEM-768的公钥大小为1184字节，密文为1088字节，是ECC的5-10倍。硬件需要更大的存储带宽和片上存储（BRAM/寄存器堆）。
- NTT引擎设计：NTT是格基算法的核心，需要设计高效的蝶形运算单元（BFU），支持可配置模数（如Kyber的q=3329，Dilithium的q=8380417），并处理模约减（Montgomery或Barrett约减）。
- 并行度与面积权衡：全并行NTT引擎吞吐率高但面积大，串行引擎面积小但延迟高。设计者需要根据目标应用（网关vs传感器）选择架构。
- 侧信道防护开销：掩码方案会使面积增加2-3倍，延迟增加1.5-2倍。如何在安全性和性能之间取得平衡是工程决策的关键。
- 异构集成：PQC硬件需要与经典密码（AES、SHA-3）协同工作，形成混合密码系统。片上总线架构（AXI4/AXI4-Lite）需要支持多算法调度。
1.5 案例拆解：从软件原型到FPGA原型验证
以一个实际的物联网安关项目为例，该网关需要支持每秒2000次ML-KEM-768密钥封装操作，同时功耗预算不超过2W。初始方案采用ARM Cortex-A53软件实现，实测性能仅为每秒320次，功耗1.8W，远不达标。
分析过程：通过性能剖析（Profiling）发现，NTT运算占用了62%的CPU周期，多项式采样占18%，哈希（SHA3-256）占12%。软件优化的空间有限，因为NTT的循环依赖限制了指令级并行。
硬件方案设计：
- 在Xilinx Zynq UltraScale+ MPSoC上实现PL端NTT加速器，采用4路并行蝶形单元，工作频率250MHz。
- 使用DMA将数据从PS DDR搬运至PL BRAM，减少CPU参与。
- SHA3-256使用Vivado HLS生成的IP核，与NTT引擎并行工作。
结果对比：
| 指标 | 纯软件 (Cortex-A53) | FPGA硬件加速 | 提升倍数 |
|---|---|---|---|
| 封装吞吐率 | 320 ops/s | 2,150 ops/s | 6.7x |
| 单次封装延迟 | 3.1 ms | 0.42 ms | 7.4x |
| 功耗 | 1.8 W | 1.2 W (PL+PS) | 降低33% |
| LUT利用率 | — | 28,400 (14%) | — |
复盘经验：硬件加速的收益不仅来自并行计算，更来自数据路径的定制化——将NTT的模约减操作融合到蝶形单元内部，避免了软件中频繁的取模运算。此外，DMA批量传输减少了CPU中断开销。该案例验证了FPGA作为PQC加速平台的可行性，也为后续ASIC设计提供了RTL基础。
1.6 常见误区与设计复盘
1.7 课程目标与学习路径
本课程旨在培养具备PQC硬件实现能力的工程人才，具体目标如下：
- 掌握PQC算法数学基础：理解格密码、哈希签名、NTT变换的数学原理，能够阅读算法规范并提取硬件实现要点。
- 精通FPGA/ASIC设计方法：掌握流水线设计、并行架构、存储优化、时序收敛等关键技术，能够独立完成从算法到RTL的映射。
- 具备侧信道防护能力：了解功耗分析、电磁分析、故障注入等攻击原理，掌握掩码、隐藏、冗余等防护措施的实现方法。
- 熟悉标准化与合规要求：理解NIST FIPS 203/204/205的测试向量和一致性要求，能够设计符合规范的硬件模块。
- 完成系统级集成：能够将PQC硬件IP集成到SoC中，处理总线接口、中断、DMA等系统问题。
学习路径分为四个阶段：第一阶段（第1-5章）夯实算法与数学基础；第二阶段（第6-15章）深入FPGA架构设计与优化；第三阶段（第16-24章）聚焦ASIC实现与物理设计；第四阶段（第25-30章）覆盖侧信道防护、系统集成与测试验证。每个阶段均配有动手实验，建议学员使用Xilinx VCK190或Intel Agilex开发板进行实践。