rustls-post-quantum 实践指南：为 Rustls 接入 ML-DSA 后量子签名与混合密钥交换

• 网络安全
• 密码学
• 网络

本指南以仓库中的 rustls-post-quantum/README.md 为核心，系统讲解 rustls-post-quantum 这个为 Rustls 提供后量子密码能力的CryptoProvider：它基于默认的 aws-lc-rs provider 构建，通过aws-lc-rs-unstable特性引入三种实验性 ML-DSA 签名算法，并梳理了 ML-KEM 密钥交换从本 crate 迁移至 rustls 主 crate 的演进脉络。读完本文，你将掌握该 crate 的定位、特性开关、ML-DSA 三种安全强度变体的源码实现位置，以及如何在项目中通过DEFAULT_PROVIDER开启后量子密码能力。

rustls-post-quantum 是什么

rustls-post-quantum 是 Rustls 生态中专门承载"实验性后量子密码支持"的配套 crate。用其 README 的原话概括，它提供的是一个构建在aws-lc-rs 默认 provider之上的CryptoProvider。

在 Rustls 的架构中，CryptoProvider是集中描述"这个 TLS 实现使用哪些密码算法"的聚合类型。从 rustls-aws-lc-rs/src/lib.rs 可以看到其核心结构，它聚合了六类能力：

• tls12_cipher_suites/tls13_cipher_suites：TLS 1.2 / 1.3 密码套件集合；
• kx_groups：密钥交换组（Key Exchange Groups）集合，包括经典曲线与后量子混合组；
• signature_verification_algorithms：证书签名验证算法集合；
• secure_random：安全随机数生成器；
• key_provider：私钥加载与签名密钥生成；
• ticketer_factory：会话票据（session ticket）生产者工厂。

rustls-post-quantum 的当前源码实现非常精简，rustls-post-quantum/src/lib.rs 中DEFAULT_PROVIDER直接复用了 aws-lc-rs provider：

use rustls::crypto::CryptoProvider; /// The default `CryptoProvider` backed by aws-lc-rs. pub const DEFAULT_PROVIDER: CryptoProvider = rustls_aws_lc_rs::DEFAULT_PROVIDER;

从依赖关系看（rustls-post-quantum/Cargo.toml），该 crate 直接依赖rustls-aws-lc-rs与rustls两个工作区成员，这正是"在 aws-lc-rs 默认 provider 之上扩展"的体现。当前仓库中的版本为0.3.0-dev.2，rust-version 要求为 1.85。

核心特性：通过aws-lc-rs-unstable启用 ML-DSA 签名

README 中声明了该 crate 唯一的特性开关：

• aws-lc-rs-unstable：增加对三种实验性ML-DSA签名算法变体的支持。

ML-DSA（Module-Lattice-Based Digital Signature Algorithm，对应 NIST FIPS 204）是目前后量子签名标准化的核心算法，其参数按矩阵维度划分出三个安全强度等级。这三个变体在 rustls-aws-lc-rs/src/verify.rs 中均有对应的SignatureVerificationAlgorithm静态实例：

从源码结构看，这三组算法在 aws-lc-rs provider 内部被组织为AwsLcRsVerificationAlgorithm，通过public_key_alg_id、signature_alg_id与底层verification_alg三元组完成算法绑定，并随SUPPORTED_SIG_ALGS一起汇入 provider 的signature_verification_algorithms字段。也就是说，即便在 rustls-post-quantum 这个包装 crate 中看不到具体的密码学实现，ML-DSA 的验证能力实际已经沉淀在rustls-aws-lc-rs这一层。

签名一侧的支撑同样完备：在 rustls-aws-lc-rs/src/sign.rs 中定义了PqdsaSigningKey（PQDSA 即 Post-Quantum Digital Signature Algorithm），它通过PqdsaKeyPair::from_pkcs8()遍历三种PqdsaKeyKind尝试解析 PKCS#8 格式的 ML-DSA 私钥，并实现SigningKeytrait 的choose_scheme()与public_key()方法，从而能够在 TLS 握手阶段为客户端证书认证等场景提供 ML-DSA 签名。在 rustls-aws-lc-rs/src/lib.rs 的KeyProvider实现中，load_private_key()在尝试完 RSA、ECDSA、Ed25519 之后，会继续尝试PqdsaSigningKey::from_pkcs8()，形成完整的私钥加载链路。

需要特别说明的是：README 中声明的aws-lc-rs-unstable特性开关对应的是发布版本（rustls 0.23.x 时代）的语义；而在当前工作区的开发版本（0.3.0-dev.2，依赖rustls 0.24.0-dev.1）中，rustls-post-quantum/Cargo.toml 尚未出现[features]段落，lib.rs也只是直接导出DEFAULT_PROVIDER。这可以推断为：ML-DSA 的实现已经整体随 rustls-aws-lc-rs 提供，特性门控的具体形态以正式发布版本为准。

ML-KEM 密钥交换：从本 crate 迁入 rustls 主 crate

README 同时记录了该 crate 的一段重要演进史：

在 rustls 0.23.22 之前，本 crate 还额外提供 ML-KEM 密钥交换支持（包括 "pure" 纯后量子与 "hybrid" 混合变体）；这些能力已迁移到 rustls crate 本身。在 rustls 0.23.22 及之后，你可以使用 rustls 的prefer-post-quantum特性，来决定是否将 ML-KEM 密钥交换优先于非后量子密钥交换。

这段历史对理解当前 rustls 的后量子能力布局至关重要：

• 职责收敛：后量子密钥交换从独立 crate 收编进 rustls 主 crate，意味着所有基于 rustls 的应用无需额外依赖即可获得 ML-KEM 支持；
• 默认开关：ML-KEM 密钥交换并非无条件启用，而是通过prefer-post-quantum特性显式决定"是否优先"。这样设计是为了保证向后兼容：默认行为下客户端仍按传统优先级协商密钥交换组，只有开启该特性后才会把 ML-KEM 相关的组排在前面。

在当前工作区的源码中可以看到这轮迁移的落地痕迹。rustls 主 crate 的密钥交换模块 rustls/src/crypto/kx/mod.rs 实现了完整的混合密钥交换（hybrid key exchange）逻辑：一个SupportedKxGroup同时承载post_quantum与经典曲线两个子算法，握手时并行产生两路密钥份额，再通过concat()把后量子份额与经典份额按post_quantum_first标记拼接为最终共享密钥。这种构造的收益是：即使未来后量子部分被攻破，经典部分的强度仍然兜底，不会出现整体失效。

而 aws-lc-rs provider 公开的密钥交换组（rustls-aws-lc-rs/src/lib.rs）清晰地列出了混合组的形态：

MLKEM768, MLKEM1024, // 纯 ML-KEM 组 SECP256R1, SECP384R1, X25519, // 经典曲线组 SECP256R1MLKEM768, X25519MLKEM768 // 混合组

其中X25519MLKEM768正是当前 rustls 主推的混合后量子密钥交换方案。rustls 的手册文档 rustls/src/manual/defaults.rs 专门介绍了它的背景：这是一个同时运行经典 X25519 与后量子 ML-KEM 的混合构造，只有两个组成部分都被攻破才会真正失效，并指出"后量子安全"（post-quantum-secure）指的是即便面对具备量子计算能力的攻击者也不易被破解的性质。

如何在项目中使用

添加依赖

在Cargo.toml中引入 rustls-post-quantum（以 crates.io 发布版本为准，本仓库内为工作区路径引用形式）：

[dependencies] rustls-post-quantum = "0.3" # 启用后量子签名特性时： rustls-post-quantum = { version = "0.3", features = ["aws-lc-rs-unstable"] }

rustls-post-quantum 内部依赖了 rustls 与 rustls-aws-lc-rs 两个核心 crate，因此无需再手动引入 aws-lc-rs provider。若你的项目同时使用 rustls，建议版本保持同步。

使用 DEFAULT_PROVIDER 构建 TLS 配置

使用导出的DEFAULT_PROVIDER构建ClientConfig/ServerConfig即可，示例（基于 rustls 当前 API）：

use std::sync::Arc; use rustls::ClientConfig; use rustls_post_quantum::DEFAULT_PROVIDER; // 以支持后量子能力的 provider 构建客户端配置 let config = ClientConfig::builder_with_provider(Arc::new(DEFAULT_PROVIDER)) .with_safe_default_protocol_versions()? .with_root_certificates(roots) .with_no_client_auth();

在 rustls 0.23.22 及之后的版本中，若你还希望"优先"使用 ML-KEM 密钥交换，需要在 rustls 依赖上开启prefer-post-quantum特性：

[dependencies] rustls = { version = "0.23", features = ["prefer-post-quantum"] }

开启后，密钥协商将优先选择X25519MLKEM768这类混合后量子组；不开启时则按传统顺序协商。需要留意的是，当前工作区中的 rustls 为0.24.0-dev.1开发版本，其 Cargo.toml 中列出的特性（brotli、tracing、webpki、zlib）尚未包含prefer-post-quantum，该开关的实际形态以发布版本为准。

关于 FIPS 的补充

由于 rustls-post-quantum 建立在 aws-lc-rs provider 之上，它也顺带继承了 aws-lc-rs 的 FIPS 能力：rustls-aws-lc-rs 提供fips特性与DEFAULT_FIPS_PROVIDER（参见 rustls-aws-lc-rs/src/lib.rs），并在其模块文档中说明了 FIPS 140-3 认证状态。若你的部署环境对合规性有硬性要求，可在此基础上进一步了解 FIPS 模式下的算法门控。

许可证与发布状态

README 最后说明：rustls-post-quantum 与 rustls 主 crate 采用相同的许可证，即Apache-2.0 OR ISC OR MIT三重许可（三选一即可）。该声明与 rustls-post-quantum/Cargo.toml 中的license = "Apache-2.0 OR ISC OR MIT"字段完全一致，适用于需要明确开源合规性的商业或学术项目。

总体而言，rustls-post-quantum 在当前 rustls 生态中的角色可以概括为：它是后量子密码能力进入 Rustls 的入口包装层——签名侧通过它声明性地引入 ML-DSA 三变体，密钥交换侧则见证了 ML-KEM 从独立 crate 收敛到 rustls 主 crate 的演进。对于希望在 TLS 栈中提前布局抗量子能力的开发者，从DEFAULT_PROVIDER入手、配合prefer-post-quantum特性进行灰度验证，是一条平滑且可回退的实践路径。

• 网络安全
• 密码学
• 网络