李卷孺，华东师范大学密码学院
密码学基础设施代码库（以下简称“密码学代码库”）是指实现了密码学核心原语算法（如对称加密、公钥加密和哈希函数）及基本安全协议（如TLS、SSH）的软件代码库。这些算法和基本协议作为支撑现代信息系统安全运行的底层密码技术体系，保障了机密性、完整性、认证性和不可否认性，支撑了HTTPS/TLS、电子签名/电子合同、区块链/数字货币、VPN、操作系统安全启动等上层安全应用，是密码学工程领域的基础设施。
自20世纪90年代互联网和开源软件生态快速发展以来，几乎所有计算机平台开始利用开源的密码学代码库构建相关的密码系统。因此，密码学代码库也是现代软件供应链安全的重要环节。然而，密码学代码库在广泛部署的同时，其实现层面的安全风险日益凸显。学术调研显示，主流密码库超过六成的安全问题源于内存缺陷与侧信道等实现层因素，而非算法设计本身；实际部署的密码解决方案普遍缺乏严格的安全审计，加之代码持续迭代，变更审计存在显著的滞后性。围绕密码学代码库开展安全重构研究，是缓解“实现层安全”这一长期痛点、提升密码体系工程韧性的关键路径。当前，代码精简、新型编程范式与形式化验证三条研究路线并行推进，而大模型的快速发展更为大规模自动化代码重构与验证提供了新的技术契机。系统梳理这一领域的风险态势与研究进展，对夯实数字时代密码基础设施安全根基具有重要的理论与实践价值。
一、密码学代码库的安全挑战与重构必要性
密码学代码库的广泛使用虽然显著地提升了现代计算机系统和互联网基础设施的安全性，但也引入了新的安全问题：密码学理论的安全威胁模型假定的安全攻击多为数学层面的分析，而现实情况下，攻击者可以利用密码学代码库软件代码中存在的各类安全缺陷来实施攻击。实际上，大量现实世界密码安全事件并非源于算法理论被攻破，而是由实现缺陷、配置错误或API误用引起。以2014年影响全球互联网安全的“心脏滴血”（OpenSSL HeartBleed）高危漏洞（编号CVE-2014-0160）为例，其根源在于OpenSSL密码学代码库的TLS Heartbeat组件缺少对网络消息中的数据字段长度的严格验证，导致攻击者可以通过构造恶意的网络数据请求，触发OpenSSL TLS Heartbeat扩展中的边界检查缺失导致的缓冲区越界读取/内存过读漏洞，继而窃取服务器上的私钥信息。
麻省理工学院的研究人员针对CVE漏洞数据库中269个密码学相关的CVE漏洞进行了调查，发现这些漏洞可以分为两大类：一是密码学代码库内在的安全缺陷；二是外部系统对密码学代码库的使用不当造成的安全问题。近年来，大量研究进一步证明，对于现代密码学体系而言，在代码层面的安全隐患更具有普遍性。2019年，剑桥大学的研究人员通过大规模实验分析揭示，OpenSSL、GnuTLS、Mozilla NSS、WolfSSL、Mbed TLS等23个主流密码库中67.8%的安全问题源于内存使用缺陷和侧信道漏洞等实现层面的问题，而非算法设计本身的缺陷。更令人担忧的是，由苏黎世联邦理工学院和伦敦国王学院的相关研究人员主导的一项密码学“田野调查”（Cryptography in the Wild）指出，实际部署的密码解决方案往往缺乏密码学理论研究中的严格安全审计或证明，使得这些保护关键数据的核心密码系统的安全性难以得到有效验证。
为解决上述问题，学术界和工业界花费了大量精力，试图改善密码学代码库的安全性，期望彻底消除其中潜在的安全隐患。许多研究人员尝试通过各种代码分析技术和分析工具，检测已有的密码学代码库中的安全漏洞并加以修复。经过研究人员的不懈努力，一些实际使用的密码学代码库的安全缺陷已陆续被发现并披露，但与已发布和部署的软件代码中使用的密码学代码库相比，经过严格和全面安全审计分析的代码占比有限，而现实世界中的密码学代码库还在不断更新，对变更代码的安全审计分析存在显著的滞后性。因此，许多研究人员转向另一类技术路线——对已有的密码学代码库进行重构，期望能够通过更为安全的设计和实现方式，在保留原有功能性的基础上，重新开发出更为安全的代码实现。
二、密码学代码库重构的三种研究路线
密码学代码库的安全重构已经受到工业界和学术界的持续关注，对其重构工作从未停止。实际上，20世纪90年代中期开始出现的第一批密码学代码库（如Cryptlib、OpenSSL的前身SSLeay、Crypto++等），直到今天依然保持更新，而新一批的密码学代码库正在不断利用新技术进行重新构建。在现实中，针对密码学代码库的改造可以分为以下三个不同的研究路线。
（一）代码精简
在OpenSSL HeartBleed安全漏洞出现之后，开发人员意识到已有的OpenSSL代码库存在大量难以维护的遗产代码（legacy code），对其进行审计难度很大，在安全要求更高的场景下存在安全隐患。因此，不同团队开发了一系列新的密码学代码库，其中由OpenBSD团队开发的LibreSSL和Google开发的BoringSSL都是从原有的OpenSSL分支而来，并进行了一系列重构：LibreSSL删除了OpenSSL中超过9万行旧有的不安全代码，特别是将一批已经不安全的密码算法（如MD5、RC4等）排除在外；BoringSSL同样只保留了现代的算法和加密模式（如AES-GCM和ChaCha20-Poly1305），而且对OpenSSL原有的数据格式解析代码（如对ASN.1和X509的解析）等部分关键模块进行了改写，以消除内存安全问题。此外，在LibreSSL和BoringSSL的开发过程中均集成了大量安全测试和安全加固策略，持续筛选和剔除可能存在的漏洞。受这些工作的启发，我国也出现了一批新开发的密码学代码库，如GmSSL、Tongsuo、OpenHiTLS等。亚马逊云平台（Amazon Web Services）于2015年在密码工程领域开源了TLS协议实现（s2n-tls）和高性能大整数算术库（s2n-bignum），目标是实现简单、安全、可审计的密码学代码库，以最为精简的实现来消除相关的安全问题，并通过减少功能（只保留实际在云端使用的功能）和强安全默认配置（去除所有弱密码算法和模式）的方法来构建可验证、可审计且高性能的密码软件栈。值得注意的是，OpenSSL的开发团队也意识到旧有代码库的不可持续性，并在2021年构建完成了一个与旧版本（1.1.1）完全平行的新版本（3.0），这个新版本通过弃用可能误导开发者的不安全API、默认关闭不安全的算法和配置选项等措施，在一定程度上完成了对OpenSSL这个经典的密码学代码库的重构。
（二）使用新型编程范式重开发
为了消除代码的安全漏洞，开发者越来越倾向于使用新型编程范式重新实现密码代码库，其中常见的策略是使用内存安全语言（如Rust、Go等）重新开发密码学算法库。Rustls是一个使用Rust程序设计语言编写的TLS库，在协议处理部分100%使用了Rust代码编写，从而保证了这部分操作的内存安全，但Rustls的其他部分并没有完全消除C/汇编代码集成或unsafe边界。除了使用安全的编程语言进行实现，还有一些密码学代码库继续使用C/C++语言进行重构。知名密码学家丹尼尔·伯恩斯坦（Daniel J. Bernstein）在2011年开发的NaCl密码学代码库遵循了几个重要的设计原则：密钥信息和内存地址独立、密钥信息不影响任何分支执行、只保留少数安全可靠的加密算法和模式、性能上保持高效。受到NaCl设计的影响，弗兰克·丹尼斯（Frank Denis）开发的Libsodium密码学代码库围绕“安全易用”这一核心理念，为开发者自动选择最安全、最合适的算法和参数配置，保证了这些配置经过严格的密码学审查。同时，API设计考虑了常见的误用场景，通过合理的默认值和清晰的错误处理机制，最大程度减少了安全漏洞的可能性。实际上，从Libsodium开发至今，仅在2025年底发现了一个安全漏洞（由作者Frank Denis本人发现），且该漏洞的产生原因是用户直接使用Libsodium的底层应用程序编程接口（API）导致，这也充分说明了Libsodium设计范式的安全性。
（三）形式化验证
通过形式化方法证明密码代码实现的正确性和内存安全是最为严谨的安全验证手段。在基于形式化方法进行密码学代码库的重构工作中，最具代表性的是由微软研究院、卡内基梅隆大学、INRIA等研究机构合作维护的Project Everest项目，该项目旨在使用F*编程语言构建并部署TLS协议及其底层加密算法等组件，并利用F*编程语言的特性来进行代码的形式化验证。Project Everest项目包含了多个子代码库，其中的HACL-*代码库使用了F*语言并生成高效C代码，实现了形式化验证。
三、大模型时代密码学代码库重构的新机遇与挑战
大语言模型的突破性进展为破解大规模代码重构的工程“瓶颈”提供了全新的技术契机，但同时也引入了极具隐蔽性的新型安全风险。
（一）大模型深度赋能重构的三大技术契机
大模型在理解复杂代码语义与跨语言生成方面的能力，能够与现有的密码学重构路径产生深度融合。
一是加速代码精简与遗产代码分析。面对包含大量历史遗留代码的复杂密码库，大模型可辅助专家分析跨文件的数据流与控制流，自动化识别废弃的API调用与冗余的非安全算法模块，显著降低了人工审计与剥离底层遗产代码的工程成本。
二是驱动跨编程范式的自动化重写。在向内存安全语言（如Rust、Go）迁移的进程中，大模型已被探索用于辅助C/C++向Rust的自动化翻译。相较于传统的基于抽象语法树（AST）的转换工具，大模型能更好地理解底层内存分配逻辑与生命周期，生成更符合新型编程范式安全特性的重写草案。
三是辅助形式化验证与证明生成。针对依赖F*或Coq等语言的形式化验证项目，大模型不仅可用于构建全面且边界条件严苛的密码学测试用例，更开始被探索用于辅助生成形式化验证所需的循环不变量（Loop Invariants）与证明策略，从而试图缓解形式化证明过程中人工编写成本极高的痛点。
（二）当前面临的核心技术“瓶颈”与挑战
尽管前景广阔，但密码学代码的极度敏感性与数学严谨性，使得大模型在直接应用于代码库重构时仍面临多重难以逾越的技术“瓶颈”。现有的实证分析揭示了以下三个核心难题。
一是代码生成中的“幻觉”与功能正确性陷阱。密码学算法依赖极其精确的数学运算（如大整数模幂、椭圆曲线标量乘法），当大模型在生成这些底层逻辑时，常表现出“貌似合理实则错误”的幻觉问题。生成的代码可能在标准测试用例下顺利通过，但在特定的边界值或非常规输入下暴露出严重的数学逻辑错误，导致加密协议失效。
二是形式化证明生成能力的本质局限。尽管大模型能生成常规的测试脚本，但在面对深度的形式化验证工具链时，其在严格的逻辑推理与数学归纳方面能力严重不足。当前，大模型难以自主生成复杂密码协议（如TLS 1.3握手状态机）或底层加密原语所需的完备证明代码，其生成的规约往往存在逻辑断层，仍需领域专家进行大量的介入与修复。
三是侧信道安全等隐蔽属性的验证真空。密码学代码不仅要求内存安全与功能正确，更要求实现过程具备防御微架构侧信道攻击的能力。例如，必须保证严格的“常量时间执行”，防止时间侧信道分析。然而，当前的大模型缺乏对底层编译器优化机制与硬件微架构的深度理解，生成的代码极易引入时间依赖的分支或缓存访问模式。自动化检测和验证大模型生成的代码是否满足侧信道安全，仍是一个未解的学术难题。
综上所述，在全面拥抱大模型时代的同时，密码学代码库的重构决不能依赖大模型的“黑盒生成”。未来，研究重心必须转向构建“大模型生成—形式化求解器验证—静态/动态严格审计”的闭环系统。在提高人工智能生成效率的同时，必须以严谨的密码工程标准守住安全底线，方能为整个软件供应链提供真正可靠的密码学基础设施。
四、结 语
正如密码学专家布鲁斯·施奈尔（Bruce Schneier）在30年前的文章中所述，攻击者的投入和技术水平在不断增长和提高，针对密码学的安全防护能力也需要不断提升。重构密码学代码库，提升其安全性、可用性和运行效率也是密码学安全发展中不可缺少的。在大模型时代，应当充分利用人工智能这一工具，让密码学代码库重构这一研究方向获得更多关注，生成可靠、高效的新型密码学代码库，为密码学和增强整个软件供应链安全性提供有效支持。
（本文刊登于《中国信息安全》杂志2026年第6期）
声明：本文来自中国信息安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
