1. 后量子密码性能评估工程导论
后量子密码（Post-Quantum Cryptography, PQC）算法在数学安全性上已经过多年公开分析，但“安全”并不等于“可用”。当NIST在2022—2024年间陆续确定ML-KEM（FIPS 203）、ML-DSA（FIPS 204）、SLH-DSA（FIPS 205）等标准后，工程界真正面对的问题变成了：这些算法放到TLS握手、代码签名、固件升级、VPN网关、智能卡等真实场景里，延迟、吞吐、内存、带宽、能耗是否可接受？性能评估工程就是回答这个问题的系统性方法。
课程定位：从算法论文到可交付的评估结论
本课程不是密码学理论课，也不是单纯的基准测试工具教程。它关注的是“如何把一次PQC性能评估做成可复现、可比较、可决策的工程活动”。评估对象包括三类：算法实现本身（参考实现、优化实现、硬件加速实现）、承载算法的协议与系统（TLS 1.3、SSH、IKEv2、CMS、固件签名链）、以及运行环境（x86-64、ARM Cortex-A/M、RISC-V、FPGA、安全元件）。同一算法在不同实现和不同平台上，性能可能相差一个数量级以上，因此评估必须绑定“算法+实现+平台+参数集+协议上下文”这一完整组合。
评估对象与关键指标体系
PQC性能评估的指标不能只盯“快不快”。一个完整的指标体系至少覆盖以下维度：
- 时间指标：密钥生成、封装/解封装、签名/验签的单次耗时，以及P50/P95/P99分位数。PQC算法耗时分布往往比RSA/ECC更分散，均值会掩盖尾延迟问题。
- 空间指标：公钥、私钥、密文、签名的字节长度，以及运行时栈/堆峰值。ML-KEM-768公钥1184字节、密文1088字节，SLH-DSA签名可达7856字节（SLH-DSA-SHA2-128s），这些直接冲击MTU、证书链和存储预算。
- 吞吐与并发：单位时间握手数、签名数，以及在多核、多连接下的扩展效率。
- 资源消耗：CPU周期、指令数、缓存缺失、能耗。嵌入式场景下能耗和RAM往往比绝对速度更关键。
- 协议级指标：握手往返次数、握手总字节数、首字节时间、连接建立成功率。
- 稳定性与一致性：多次运行方差、不同编译器/优化等级下的行为差异、常数时间特性是否被破坏。
这些指标之间存在权衡。例如ML-KEM封装快、密文小，但ML-DSA签名体积大；SLH-DSA签名极慢但安全假设保守。评估工程的任务不是找“最快”，而是给出在给定约束下的可解释取舍。
工程化流程：一次评估如何闭环
把评估做成工程，需要固定流程而非临时跑分。典型闭环如下：明确评估问题与决策目标 → 选定算法、参数集与实现 → 搭建可复现的测量环境 → 设计测量方法与负载模型 → 采集原始数据 → 统计与归一化 → 结果判读与结论输出 → 归档以便复现。其中“测量环境”必须记录CPU型号、频率策略、编译器版本与优化选项、是否开启AVX2/NEON、操作系统与内核、是否隔离CPU核等。缺少这些元数据，数据无法跨团队比较。
测量方法上要区分微基准（microbenchmark）与系统级基准。微基准用固定输入反复调用API，适合比较实现质量；系统级基准在真实协议栈中跑握手或签名链，适合回答“能不能上线”。两者不可互相替代。采样时建议先做预热，丢弃前若干次；每项至少重复30次以上，报告中给出中位数与P95，而不是只给一个“平均耗时”。
结果判读与常见误区
拿到数据后，第一步是检查可比性：两次测量是否在同一平台、同一编译选项、同一负载下完成。第二步是看尾延迟与方差，PQC实现中分支预测失败、缓存抖动、随机数生成都可能造成长尾。第三步是把算法指标映射回业务SLA，例如“TLS握手P95增加不超过15毫秒”“固件签名验证不超过200毫秒”。第四步是记录不确定性：哪些结论是稳健的，哪些依赖特定平台。
常见误区包括：只测均值不测分位数；把不同参数集混在一张表里比较；忽略密钥/签名体积对网络和存储的二次影响；在开启频率boost的机器上测完就下结论；以及把一次跑分当作可复现结论。评估工程的价值恰恰在于用规范流程消除这些偏差。