Open Quantum Safe (liboqs) 项目中的内部API与公共API分离优化方案

在密码学库开发过程中，合理划分内部实现和公共接口是保证软件架构清晰性和安全性的重要实践。Open Quantum Safe项目的liboqs库近期针对这一问题进行了深入讨论和优化。

背景与问题分析

liboqs作为一个提供后量子密码学算法的开源库，其代码结构中包含了一些仅供内部使用的功能实现，如SHA2、SHA3哈希算法和AES加密的实现代码。这些实现虽然被标记为非公共API，但当前构建系统仍会将它们的头文件安装到系统include目录中，这可能导致以下问题：

1. 用户可能误用这些非稳定接口
2. 增加了不必要的API表面区域
3. 可能引发未来的兼容性问题

同时，这些内部实现需要被测试程序访问以验证其正确性，这给构建系统设计带来了挑战。

技术解决方案

项目团队提出了一个优雅的解决方案：创建独立的内部库oqs-internal。该方案具有以下技术特点：

1. 模块化分离：将内部实现代码(aes.h、sha2.h、sha3.h等)封装到独立的oqs-internal库中
2. 构建系统优化：通过CMake配置确保内部库仅用于构建过程，不参与安装
3. 访问控制：设置适当的可见性属性(default)，使测试程序可以链接访问
4. 架构扩展性：为未来可能的内部共享代码提供了清晰的扩展路径

实现细节

在技术实现层面，该方案涉及以下关键点：

1. CMake配置中明确区分PUBLIC_HEADERS和INTERNAL_HEADERS
2. 创建独立的库目标(target)用于内部实现
3. 调整测试程序的链接依赖关系
4. 确保安装逻辑仅包含真正的公共头文件

优势与收益

这一架构改进带来了多方面好处：

1. 接口清晰性：用户只能访问设计为稳定的公共API
2. 测试便利性：测试程序仍可方便访问所有必要实现
3. 跨平台兼容：特别解决了MacOS上共享库构建时的链接问题
4. 维护友好：为未来的代码扩展提供了明确模式

总结

liboqs项目通过引入内部库的架构设计，优雅地解决了密码学库开发中常见的接口边界问题。这种方案不仅解决了当前的具体问题，还为项目未来的发展奠定了良好的架构基础，值得类似项目参考借鉴。这种分离内部实现与公共接口的做法，体现了专业密码学库开发的最佳实践。