Spaces:

Jack698
/

ucissl

Build error

// 新增文件：include/openssl_adapter.h, src/openssl_adapter.c

int openssl_rsa2048_keygen(uci_keypair_t *keypair) {
    EVP_PKEY *pkey = NULL;
    EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
    
    // 生成2048位RSA密钥
    EVP_PKEY_keygen_init(ctx);
    EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048);
    EVP_PKEY_keygen(ctx, &pkey);
    
    // 导出为DER格式
    i2d_PUBKEY(pkey, &pub_der);
    i2d_PrivateKey(pkey, &priv_der);
    
    // 存储到UCI结构
    keypair->public_key = pub_der;
    keypair->private_key = priv_der;
    // ...
}

参考来源

oqs-provider: 学习了其对OpenSSL API的封装方式
OpenSSL文档: EVP_PKEY API的使用

2. 改进算法注册机制

借鉴oqs-provider的设计

oqs-provider使用Provider API注册算法：

// oqs-provider方式
static const OQSX_PROVIDER_KEYMGMT dilithium2_keymgmt = {
    .name = "dilithium2",
    .keysize = OQS_SIG_dilithium_2_length_public_key,
    // ...
};

UCI采用类似但更灵活的方式：

// UCI方式
uci_algorithm_impl_t impl;
impl.info.name = "Dilithium2";
impl.info.id = UCI_ALG_DILITHIUM2;
impl.keygen = pqc_dilithium2_keygen;
impl.sign = pqc_dilithium2_sign;
impl.verify = pqc_dilithium2_verify;
registry_register_algorithm(&impl);

优势对比

特性	oqs-provider	UCI
依赖关系	必须有OpenSSL 3.0+	独立，可选OpenSSL
灵活性	受Provider API限制	完全自主设计
多库支持	仅LibOQS	OpenSSL, LibOQS, GmSSL
学习曲线	需要了解Provider API	简单直观的注册机制

3. 多适配器架构

借鉴GmSSL兼容层的思路

GmSSL兼容层的核心思想：

// GmSSL兼容层：模拟OpenSSL接口
RSA *RSA_new(void) {
    // 内部使用GmSSL实现
    return gmssl_rsa_new();
}

UCI的改进：不是模拟接口，而是适配多个库到统一接口：

应用调用: uci_keygen(UCI_ALG_RSA2048, &keypair)
              ↓
注册表查找: 找到openssl_rsa2048_keygen
              ↓
OpenSSL适配器: 调用OpenSSL EVP API
              ↓
返回统一格式的密钥

适配器层次

┌────────────────────────────────────┐
│      unified_crypto_interface      │  统一接口层
└────────────────────────────────────┘
                 ↓
┌────────────────────────────────────┐
│       algorithm_registry           │  注册管理层
└────────────────────────────────────┘
                 ↓
    ┌────────────┬────────────┬────────────┐
    ↓            ↓            ↓            ↓
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐
│OpenSSL  │ │LibOQS   │ │GmSSL    │ │Hybrid    │  适配器层
│Adapter  │ │Adapter  │ │Adapter  │ │Adapter   │
└─────────┘ └─────────┘ └─────────┘ └──────────┘
    ↓            ↓            ↓            ↓
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐
│OpenSSL  │ │LibOQS   │ │GmSSL    │ │Composite │  底层库
└─────────┘ └─────────┘ └─────────┘ └──────────┘

4. 设计决策文档

新增了docs/design_decisions.md，详细记录：

为什么选择独立接口而非OpenSSL Provider
- 毕设定位：统一接口设计 vs OpenSSL扩展
- 灵活性：支持多库 vs 绑定OpenSSL
- 研究价值：接口抽象能力的体现
算法注册机制的设计
- 借鉴oqs-provider的动态注册思想
- 改进为更通用的注册表机制
适配器模式的应用
- 学习GmSSL兼容层的适配思路
- 设计多对一的适配架构
数据格式的统一
- DER编码作为内部格式
- 可扩展为PEM格式的导入导出
混合密码方案的实现
- 串联格式的密钥和签名
- 双重验证策略
错误处理和内存管理
- 统一的错误码体系
- 明确的内存所有权规则

5. 与参考项目的关系

oqs-provider

借鉴的内容：

✅ 算法注册机制的思想
✅ 初始化和清理的流程
✅ 算法元信息的管理方式

没有采用的内容：

❌ OpenSSL Provider API（保持独立性）
❌ 完全依赖LibOQS（支持多库）
❌ OpenSSL的错误处理机制（统一错误码）

GmSSL兼容层

借鉴的内容：

✅ 适配器模式的设计
✅ 接口转换的方法
✅ 参数类型的映射

没有采用的内容：

❌ 完全模拟OpenSSL API（设计独立API）
❌ 单向适配（双向适配多个库）
❌ 兼容性优先（功能完整性优先）

6. 项目价值提升

学术价值

接口抽象能力：展示了如何设计通用的密码服务接口
多库集成能力：证明了接口的通用性和灵活性
架构设计能力：清晰的分层和职责划分

工程价值

实用性：可以直接用于实际项目
可扩展性：易于添加新算法和新库
可维护性：清晰的代码结构和文档

创新点

独立统一接口：不依赖特定密码库的统一API
算法敏捷：运行时动态选择和切换算法
混合密码：透明的混合方案支持

7. 后续改进计划

短期（已规划）

✅ 添加OpenSSL适配器
✅ 完善文档说明
✅ 记录设计决策
⏳ 添加更多示例程序
⏳ 性能测试和优化

中期（可选）

⏳ PEM格式的密钥导入导出
⏳ X.509证书集成
⏳ 硬件加速支持（HSM/TPM）
⏳ 更多的抗量子算法（SPHINCS+等）

长期（研究方向）

⏳ 密码敏捷性的自动化
⏳ 性能优化和基准测试
⏳ 与标准协议的集成（TLS 1.3等）
⏳ 分布式密钥管理

8. 总结

通过研究oqs-provider和GmSSL兼容层，我们：

明确了方向：独立统一接口 vs OpenSSL扩展
借鉴了优秀设计：算法注册、适配器模式
保持了独特性：UCI的独立价值和创新点
提升了质量：完善的OpenSSL集成和文档

这些改进使UCI更加完整和实用，同时保持了作为毕业设计的学术价值和创新性。

项目改进说明

改进概述

1. 添加OpenSSL适配器

改进前

改进后

代码示例