1. 课程导入与工程全景

在传统 TLS 体系中，身份认证依赖 RSA 或 ECDSA 数字签名，密钥交换依赖 ECDHE。这套机制的安全性建立在“大整数分解”和“椭圆曲线离散对数”两类数学难题之上。然而，Shor 算法在足够规模的量子计算机上可以在多项式时间内求解这两类问题，这意味着当前部署的绝大多数 TLS 证书和密钥交换机制，在量子计算成熟后将不再安全。这就是 PQC（Post-Quantum Cryptography，后量子密码）要解决的核心问题。

但 PQC 并不是简单地“换一种算法”。它带来三个工程层面的连锁反应：第一，密钥和签名尺寸显著增大，例如 ML-KEM-768 的公钥约 1184 字节、密文约 1088 字节，而 X25519 公钥仅 32 字节；第二，算法族从单一体系变为多体系并存，KEM（密钥封装机制）与签名算法需要分别选型；第三，协议栈、证书格式、硬件加速、性能预算都要重新评估。本课程的目标，就是把这些变化落到可部署、可验证的工程实践中。

本节要解决的核心问题

本课程围绕一条主线展开：在真实服务网格与网关环境中，如何用 PQC 算法完成 mTLS 双向身份认证，并保证性能、兼容性与可运维性。围绕这条主线，需要回答四个具体问题：

• 算法选型问题：ML-KEM（原 Kyber）、ML-DSA（原 Dilithium）、SLH-DSA（原 SPHINCS+）分别适合什么场景？混合模式（如 X25519+ML-KEM-768）为什么是过渡期首选？
• 证书与信任链问题：PQC 证书的 OID、公钥编码、签名算法标识如何表达？CA 如何签发和验证？
• 协议集成问题：TLS 1.3 的 key_share、signature_algorithms、certificate 消息如何承载 PQC 数据？握手包大小膨胀后如何避免分片失败？
• 工程验证问题：如何用 openssl、oqs-provider、curl 或自建客户端验证握手成功？如何测量握手延迟、CPU 占用和吞吐变化？

技术栈边界

本课程的技术栈边界需要明确，避免把“密码学理论”和“工程实现”混为一谈。我们不深入讲解格密码的数学证明、NTT 变换的推导或安全归约；我们要掌握的是：算法参数集、密钥/签名/密文的字节级结构、OpenSSL 3.x + oqs-provider 的配置方式、TLS 1.3 握手中 PQC 扩展的实际位置、以及用抓包和日志判断握手是否真正使用了 PQC 算法。

下图给出本课程的技术栈全景：从底层算法库，到证书与信任链，再到 TLS 协议集成，最后到服务网格与网关的部署验证。每一层都有明确的输入、输出和可观测点。

学习路径与实战项目

课程按“先建认知、再动手、后验证”的节奏推进，共 30 章，分为五个阶段：

1. 基础认知（第 1–6 章）：理解 PQC 算法族、NIST 标准化进程、mTLS 握手流程，以及 PQC 对证书格式和协议扩展的影响。
2. 环境搭建（第 7–12 章）：编译 liboqs 与 oqs-provider，配置 OpenSSL 3.x，生成 PQC 根 CA、中间 CA 和叶子证书，验证签名与验签。
3. 协议集成（第 13–20 章）：在 TLS 1.3 握手中启用混合密钥交换，分析 ClientHello/ServerHello 的字节结构，处理大包分片与超时问题。
4. 服务网格落地（第 21–26 章）：将 PQC mTLS 接入 Envoy/Istio，配置 SDS 证书分发，测量握手延迟与吞吐，调优线程与缓冲区。
5. 验证与复盘（第 27–30 章）：用抓包、日志和性能指标判断 PQC 是否真正生效，输出可复现的测试报告与迁移建议。

贯穿全课程的实战项目是：为一个双服务（frontend → backend）的 Kubernetes 环境，部署基于 ML-KEM-768 + ML-DSA-65 的 mTLS 身份认证，并用 openssl s_client 和自定义 Go 客户端验证握手成功、测量握手延迟，最后输出一份包含配置、日志和性能数据的验证报告。这个项目会在各阶段逐步搭建，最终形成可运行的完整方案。

关键参数速查

为了后续章节查阅方便，这里先给出本课程最常用的三组算法参数（均为 NIST 标准参数集，示例值来自公开规范）：

可以看到，PQC 的尺寸膨胀是数量级的：ML-KEM-768 的公钥是 X25519 的 37 倍，ML-DSA-65 的签名是 ECDSA P-256 的约 55 倍。这直接导致 TLS 握手包从几 KB 膨胀到十几 KB，可能触发 TCP 分片或 MTU 问题。后续章节会专门处理这些工程细节。