面向应用程序开发人员的后量子密码建议攻略

亲爱的维护者们， 我想提议一份新的《后量子密码学指南》，适用于应用程序开发人员。 目前，OWASP 已经在各个项目中涵盖了 PQC 的各个方面，并在特定的指南中对其进行了介绍： 1.《传输层安全性指南》明确地讨论了 X25519MLKEM768 和 OpenSSL、Apache 和 NGINX 的配置示例。 2.《JSON Web Token 指南》介绍了 ML-DSA 和混合 ML-DSA 签名，包括它们的大签名大小影响。 3.《SAML 安全性指南》讨论了在 PQC 普遍使用时需要支持额外的签名算法的必要性。 4.《OWASP 十大安全漏洞》告诉组织，他们已经需要为 PQC 做好准备，并引用了 NIST/ENISA 的指导。 5.《Web 安全性测试指南》明确地介绍了 PQC 测试指南，包括 ML-DSA、ML-KEM 和混合 X25519+ML-KEM。 6.《OWASP MAS/MASTG》有一个单独的《后量子部分》，提到了 ML-KEM、ML-DSA 和 SLH-DSA。 7.《OWASP IoT 安全验证标准》为预计在 2030 年之后运行的设备提出了 PQC 要求。 此外，OWASP 已经开始在其应用程序安全标准中考虑 PQC。 ASVS 问题 #3140 和 #3361 表明，项目中已经在讨论后量子密码学，包括“收获现在，解密后”、“长期保密”、“长期签名”、“混合密码学”和 PQC 原语等主题。 因此，本提案的目的是不是要重复、替代或整合现有的所有 PQC 技术指南。 我也查看了《指南项目》中已有的问题和 PR，以检查是否存在重叠或重复，但我没有找到与 PQC 相关的内容。 因此，似乎有机会编制一个集中式、以应用程序开发人员为中心的指南，回答一个实际问题：“应用程序开发人员今天应该如何准备其应用程序以适应过渡到后量子密码学？”“考虑到我应用程序现有的密码架构，我应该如何考虑后量子迁移？” 提出的《指南》将补充现有的 OWASP 指导，而不是取代或重复它们。 因此，范围可能包括： 1.了解应用程序的暴露 — 应用程序实际上依赖哪些密码机制和协议？ 2.分类密码用例 — 加密/密钥建立与签名与传输与存储数据。 3.考虑迁移影响 — 当底层算法或协议需要更改时，会发生什么变化？ 4.混合方法 — 在支持的情况下，开发人员应该如何思考经典 + PQC 机制？ 5.密码灵活性 — 应用程序如何避免硬编码密码假设？ 6.依赖和协议 — 当框架、库、协议或外部服务尚不支持所需的 PQC 机制时会发生什么？ 7.准备清单 — 即使迅速迁移不可行，开发人员现在也可以做些什么？ …