Msubasi1/Post-Quantum-Cryptography-TLS

GitHub: Msubasi1/Post-Quantum-Cryptography-TLS

这是一个用 C 语言编写的 TLS 1.3 实现,通过集成后量子密钥交换算法来增强网络通信的安全性,以应对量子计算威胁。

Stars: 0 | Forks: 0

# 抗量子网络安全:后量子 TLS 一个从零开始用 C 编写的 TLS 1.3 服务器和客户端,在握手过程中使用**后量子密钥封装**(ML-KEM / Kyber、Falcon、SPHINCS+)。基于 OpenSSL 3.0.8 构建,并采用 [Open Quantum Safe](https://openquantumsafe.org/) 提供程序,该项目证明了抗量子密钥交换如今即可部署,且仅带来**约 13% 的握手开销** —— 同时准确记录了当前库仍存在不足之处(X.509 证书中的 PQ 签名)。 ![C](https://img.shields.io/badge/C-C99-A8B9CC?logo=c&logoColor=white) ![OpenSSL](https://img.shields.io/badge/OpenSSL-3.0.8-721412?logo=openssl&logoColor=white) ![liboqs](https://img.shields.io/badge/liboqs-open--quantum--safe-blue) ![TLS](https://img.shields.io/badge/TLS-1.3-green) ![Ubuntu](https://img.shields.io/badge/Ubuntu-22.04-E95420?logo=ubuntu&logoColor=white) ![License](https://img.shields.io/badge/License-MIT-green) ## 动机 在足够大的容错量子计算机上运行的 Shor 算法可以破解当前大规模部署的所有公钥密码系统 —— RSA、ECC、Diffie-Hellman。保守估计,具有密码学意义的量子计算机还需要 10-15 年。然而,威胁**已在实际中存在**,源于“现在收集,日后解密”的攻击:攻击者记录当前的加密流量,并在量子计算机可用时进行解密。 NIST 于 2024 年标准化了首批四种后量子算法: - **ML-KEM**(原 Kyber)—— 基于格的密钥封装 - **ML-DSA**(原 Dilithium)—— 基于格的数字签名 - **Falcon** —— 基于格的紧凑签名 - **SPHINCS+** —— 基于哈希的签名 本项目使用这些算法实现了 TLS 1.3,测量了其开销,并指出了集成中所有仍显粗糙的地方。 ## 方法 使用 C 语言针对 **OpenSSL 3.0 提供程序 API** 编写了定制的 TLS 服务器和客户端,而不是使用高级 TLS 库 —— 这是唯一能够详细检查提供程序加载、算法发现和握手协商的方式。OQS Provider 插入 OpenSSL 并通过标准的 `EVP_*` 接口暴露后量子算法。 系统栈: | 层 | 组件 | 用途 | |---|---|---| | 密码核心 | OpenSSL 3.0.8(从源码构建) | 提供程序架构 | | PQ 算法 | [liboqs](https://github.com/open-quantum-safe/liboqs) | 参考实现 | | 桥接 | [oqs-provider](https://github.com/open-quantum-safe/oqs-provider) | 将 PQ 算法作为 OpenSSL 提供程序暴露 | | 应用 | `pqc_tls_server.c`, `pqc_tls_client.c` | 定制 TLS 端点 | | 操作系统 | Ubuntu 22.04(通过 UTM 的 ARM64) | 构建目标 | ## 已验证的算法 **密钥封装 (KEM) —— 在 TLS 1.3 握手中完全可用** - `mlkem512`, `mlkem768`, `mlkem1024` - 混合模式:`X25519MLKEM768`, `SecP256r1MLKEM768`, `x25519_mlkem512` - `frodo640aes`, `frodo976aes`, `frodo1344aes` - `bikel1`, `bikel3`, `bikel5` **签名 —— 提供程序可识别,但在 OpenSSL 3.0.8 的 X.509 证书层被阻止** - `falcon512`, `falcon1024` - `mldsa44`, `mldsa65`, `mldsa87`(Dilithium 变体) - `sphincssha2128fsimple`, `sphincssha2192fsimple` - 混合模式:`rsa3072_falcon512`, `p256_mldsa44`, 等 ## 结果 ### 密码原语性能(签名/秒,密钥与签名大小) | 算法 | 密钥大小 | 签名大小 | 签名/秒 | 安全等级 | |-----------|----------|----------|--------|----------| | Dilithium2 | 1312 B | 2420 B | **16,182** | NIST L1 | | Dilithium3 | 1952 B | 3293 B | 10,394 | NIST L3 | | Falcon512 | 897 B | **690 B** | 8,917 | NIST L1 | | SPHINCS+ | 32 B | 7,856 B | 97 | NIST L1 | | RSA-3072 | 384 B | 384 B | 245 | 经典 | | ECDSA P-256 | 32 B | 64 B | 4,721 | 经典 | | ECDSA P-384 | 48 B | 96 B | 1,534 | 经典 | - **Dilithium2 的签名速度是 RSA-3072 的 66 倍**,证明了后量子密码并非天生缓慢。 - **Falcon512 的 PQ 签名最小**(690 B),这对协议大小受限的场景很重要。 - **SPHINCS+ 以性能换取安全性**:基于哈希且保守,但速度慢两个数量级。 ### 每个操作的内存占用 | 算法 | 栈 | 堆 | 总计 | |-----------|------|------|-------| | Dilithium2 | 41 KB | 2.1 KB | 43.1 KB | | Falcon512 | 39 KB | 1.8 KB | 40.8 KB | | Kyber768 | 2.4 KB | 1.6 KB | **4.0 KB** | | RSA-3072 | 8 KB | 1.2 KB | 9.2 KB | Kyber768 —— 在量子安全握手中承担主要工作的 KEM —— 实际上**比 RSA-3072 使用更少的内存**。 ### TLS 握手时序(本地主机上的定制客户端 ↔ 定制服务器) | 配置 | 密钥交换 | 认证 | 总握手时间 | |---|---|---|---| | 纯经典 (X25519 + RSA-3072) | 15 ms | 8 ms | **98 ms** | | 经典 TLS | 15 ms | 12 ms | 112 ms | | **混合 MLKEM768 + RSA-3072** | **18 ms** | 12 ms | **127 ms (+13.4%)** | 添加 PQ 密钥交换仅增加约 3 毫秒的密钥协商时间和约 15 毫秒的总握手开销。这是 2025 年量子安全 TLS 的实际成本 —— 足够小,使得生产部署不再是一个性能问题。 ### “50% 量子安全” 握手被拆分:密钥交换 (KEM) ✅ 对比认证 (签名) ❌。KEM 部分完全抗量子 —— ML-KEM 派生会话密钥。认证部分仍然使用 RSA-3072,因为 OpenSSL 3.0.8 尚未在 X.509 证书链中识别 PQ 算法。因此,会话密钥对“现在收集,日后解密”攻击是安全的,但量子攻击者今天仍然可以伪造新证书。这个限制是一个工具问题(在 OpenSSL 3.5+ 中已解决),而不是密码学问题。 完整讨论见 [`docs/CMP_656_Final_Report.pdf`](docs/CMP_656_Final_Report.pdf)。 ## 安装 需要 Ubuntu 22.04(或兼容的 Debian),≥8 GB 内存,~10 GB 可用空间。从源码构建 OpenSSL + liboqs + oqs-provider —— 目前尚无 apt/dnf 快捷方式。 ### 一键安装 ``` git clone https://github.com/Msubasi1/Post-Quantum-Cryptography-TLS.git cd Post-Quantum-Cryptography-TLS ./create_project_structure.sh # Set up directory tree ./deploy_complete_project.sh # Builds OpenSSL 3.0.8 + liboqs + oqs-provider ``` 部署脚本会将正确的 `LD_LIBRARY_PATH`、`OPENSSL_CONF` 和 PATH 条目写入您的 shell rc 文件 —— 在继续之前请重新加载它 (`source ~/.bashrc`)。 ### 手动安装 ``` sudo apt update && sudo apt install -y build-essential cmake ninja-build git wget curl # 从源码编译 OpenSSL 3.0.8 wget https://www.openssl.org/source/openssl-3.0.8.tar.gz && tar -xzf openssl-3.0.8.tar.gz cd openssl-3.0.8 ./Configure linux-$(uname -m) --prefix=/usr/local/openssl --openssldir=/usr/local/openssl shared make -j$(nproc) && sudo make install cd .. # liboqs git clone https://github.com/open-quantum-safe/liboqs.git cd liboqs && mkdir build && cd build cmake -GNinja -DCMAKE_INSTALL_PREFIX=/usr/local/liboqs -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON .. ninja && sudo ninja install cd ../.. # oqs-provider git clone https://github.com/open-quantum-safe/oqs-provider.git cd oqs-provider cmake -S . -B _build -DCMAKE_PREFIX_PATH="/usr/local/liboqs;/usr/local/openssl" -DCMAKE_INSTALL_PREFIX=/usr/local/openssl cmake --build _build --parallel $(nproc) sudo cmake --install _build cd .. # 环境 echo 'export PATH="/usr/local/openssl/bin:$PATH"' >> ~/.bashrc echo 'export LD_LIBRARY_PATH="/usr/local/openssl/lib64:/usr/local/liboqs/lib:$LD_LIBRARY_PATH"' >> ~/.bashrc echo 'export OPENSSL_CONF=/usr/local/openssl/openssl.cnf' >> ~/.bashrc source ~/.bashrc ``` ## 用法 ``` # 1. 验证构建是否正常 ./tests/debug_tools.sh ./tests/algorithm_discovery.sh # 2. 生成测试证书 ./certificates/generate_certs.sh # 3. 编译 TLS 端点 cd src && ./compile.sh cd .. # 4. 运行服务器(终端 1) ./src/pqc_tls_server # 5. 使用客户端连接(终端 2) ./src/pqc_tls_client ``` 如果握手完成,您将看到: ``` ✓ Providers loaded successfully ✓ Quantum-safe key exchange: MLKEM768 ✓ QUANTUM-SAFE KEY EXCHANGE ACTIVE! ``` ### 运行完整的基准测试套件 ``` ./tests/run_all_tests.sh ./benchmarks/run_benchmarks.sh ./benchmarks/tls_performance_test.sh ``` ## 项目结构 ``` Post-Quantum-Cryptography-TLS/ ├── src/ │ ├── pqc_tls_server.c # Custom TLS 1.3 server with PQ provider loading │ ├── pqc_tls_client.c # Custom TLS 1.3 client with PQ KEM negotiation │ └── compile.sh # Build script (links OpenSSL 3.0 + oqs-provider) ├── certificates/ │ └── generate_certs.sh # Generates RSA-3072 server cert for testing ├── tests/ │ ├── algorithm_discovery.sh # Enumerate KEMs and signatures the provider exposes │ ├── debug_tools.sh # Sanity checks on the build / env │ ├── run_all_tests.sh # Full test runner │ └── analyze_logs.sh # Parse handshake logs ├── benchmarks/ │ ├── run_benchmarks.sh # Algorithm primitive benchmarks │ └── tls_performance_test.sh # End-to-end TLS handshake timing ├── experiments/ │ └── build_variants.sh # Alternative builds (different OpenSSL/liboqs versions) ├── deploy_complete_project.sh # One-shot installer ├── create_project_structure.sh # Set up directory layout ├── docs/ │ └── CMP_656_Final_Report.pdf ├── LICENSE └── README.md ``` ## 已知问题 - **`Provider loading failed`** —— 确保已导出 `OPENSSL_CONF=/usr/local/openssl/openssl.cnf`,并且 openssl 二进制文件是 3.0.8 构建版本(`which openssl` 必须指向 `/usr/local/openssl/bin`)。 - **`Algorithm not available`** —— oqs-provider 未正确安装。重新运行 `./tests/algorithm_discovery.sh` 以查看提供程序实际暴露了哪些算法。 - **PQ 签名无法在 X.509 证书中使用** —— OpenSSL 3.0.8 的限制。在 OpenSSL 3.5+ 中已解决。目前,使用 RSA-3072 证书进行认证,使用 ML-KEM 进行密钥交换。 - **在某些 ARM64 发行版上构建失败** —— 使用 `experiments/build_variants.sh` 配置或回退到预构建的 liboqs Docker 镜像。 ## 参考文献 - D. Moody. *Post-Quantum Cryptography Standardization*. NIST, 2024. - M. Mosca. *Cybersecurity in an Era with Quantum Computers.* IACR 2018. - C. Paquin et al. *Benchmarking Post-Quantum Cryptography in TLS.* PQCrypto 2020. - [Open Quantum Safe project](https://openquantumsafe.org/) - [OpenSSL Provider documentation](https://www.openssl.org/docs/man3.0/man7/provider.html) ## 引用 ``` Subasi, M. (2025). Quantum-Resistant Network Security: Implementing Post-Quantum Cryptography in TLS. CMP656, Hacettepe University. ``` ## 作者 **Muhammet Subasi** —— 哈斯特帕大学,计算机工程系
标签:C语言编程, Falcon签名, liboqs库, ML-KEM算法, NIST标准化, OpenSSL库, SPHINCS+签名, TLS协议, X.509证书, 加密通信, 后量子密码学, 安全协议, 密码学, 密钥封装, 库集成, 性能测试, 手动系统调用, 握手协议, 网络安全, 量子安全, 量子抵抗加密, 量子计算威胁, 隐私保护