网络安全密码学网络【免费下载链接】rustlsA modern TLS library in Rust项目地址https://gitcode.com/gh_mirrors/ru/rustls点击查看免费下载本指南以仓库中的 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_suitesTLS 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 provideruse 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.2rust-version 要求为 1.85。核心特性通过aws-lc-rs-unstable启用 ML-DSA 签名README 中声明了该 crate 唯一的特性开关aws-lc-rs-unstable增加对三种实验性ML-DSA签名算法变体的支持。ML-DSAModule-Lattice-Based Digital Signature Algorithm对应 NIST FIPS 204是目前后量子签名标准化的核心算法其参数按矩阵维度划分出三个安全强度等级。这三个变体在 rustls-aws-lc-rs/src/verify.rs 中均有对应的SignatureVerificationAlgorithm静态实例算法安全强度类别矩阵维度rustls 中定义的常量源码位置ML-DSA-44Category 2[4, 4]ML_DSA_44verify.rsML-DSA-65Category 3[6, 5]ML_DSA_65verify.rsML-DSA-87Category 5[8, 7]ML_DSA_87verify.rs从源码结构看这三组算法在 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 中定义了PqdsaSigningKeyPQDSA 即 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 主 crateREADME 同时记录了该 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 当前 APIuse 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特性进行灰度验证是一条平滑且可回退的实践路径。赞分享网络安全密码学网络【免费下载链接】rustlsA modern TLS library in Rust项目地址https://gitcode.com/gh_mirrors/ru/rustls点击查看免费下载相关推荐rustls 后量子混合密钥交换X25519MLKEM768的握手性能测量与优化实践rustls 后量子混合密钥交换X25519MLKEM768的握手性能测量与优化实践 本文基于 rustls 官方性能报告2024 12 17整理系统网络安全密码学网络GenForce模型动物园详解50预训练GAN模型一站式获取与使用GenForce模型动物园详解50预训练GAN模型一站式获取与使用 GenForce是一个高效的PyTorch深度学习生成建模库提供了丰富的预训练GAN模cryptography 库 ML-DSA 抗量子签名实战指南FIPS 204 密钥生成、签名与外部 mu 模式cryptography 库 ML DSA 抗量子签名实战指南FIPS 204 密钥生成、签名与外部 mu 模式 本篇指南围绕 cryptography ht密码学上一篇Yew 服务端渲染SSR完全指南ServerRenderer、Suspense 数据获取与 Hydration 实战下一篇如何智能解决IDM试用期限制3步实现专业级永久免费使用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考