crypto

在开发涉及加密通信或数据保护的应用时，直接调用底层密码学算法（如 AES、RSA、SHA）既繁琐又容易出错。OpenSSL 提供了 EVP（EnVElope Password）编程接口，将底层算法封装为统一的 API，开发者无需关心算法细节，只需调用统一的函数即可完成加密、哈希、签名等操作。 为什么使用 EVP 接口 直接使用 OpenSSL 的底层 API（如 AES_* 系列函数）存在以下问题： 算法切换困难：代码与特定算法强耦合，换算法需要大幅修改 安全风险：开发者可能忽略填充模式、IV 初始化等关键细节 接口不一致：不同算法的 API 风格各异，学习成本高 EVP 接口解决了这些问题： 统一 API：所有算法使用相同的使用模式 自动填充：AEAD 模式自动处理填充 易于切换：一行代码即可切换算法 内存安全：自动管理临时缓冲区 EVP 加密解密 EVP_CIPHER 相关的 API 用于对称加密和解密。以下是一个完整的示例，演示如何使用 EVP 接口进行 AES-256-GCM 加密： 加密示例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 #include <openssl/evp....

升级到 OpenSSL 3.x 后，很多老系统生成的证书无法验证通过，错误提示类似 error:0308010C:digital envelope routines。这通常是因为 OpenSSL 3.0 默认禁用了遗留算法（MD5、SHA-1、DES、RC4 等）。本文介绍如何配置 Legacy Provider 来处理这些遗留证书。 问题背景 OpenSSL 3.0 引入了 Provider 架构，密码学算法的实现被分离到独立的 Provider 中： Default Provider：提供现代安全算法（AES、SHA-2、ChaCha20 等） FIPS Provider：提供 FIPS 140-2 认证的算法 Legacy Provider：提供遗留算法（MD5、SHA-1、DES、RC4、CAST 等） 默认情况下，只有 Default Provider 启用，因此使用遗留算法的操作会失败。 验证问题现象 1. DES 加密失败 1 2 3 4 5 $ echo -n "test" | openssl enc -des-ede3-cbc enc: Unknown cipher: des-ede3-cbc error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported: ../crypto/evp/evp_fetch.c:386:Global default library context, Algorithm (des-ede3-cbc : 27), Properties (<null>) 2....

OpenSSL 3.0 引入的 Provider 架构是其最重要的架构变革之一。它将密码学算法的实现与 OpenSSL 核心解耦，使得算法可以独立加载、更新和替换。本文深入解析 Provider 的工作机制。 为什么需要 Provider？ 在 OpenSSL 1.1.x 及之前版本中，所有密码学算法（对称加密、非对称加密、哈希、签名等）都内置在 OpenSSL 库中。这种架构存在以下问题： 紧耦合：算法实现与核心库绑定，无法独立更新 扩展困难：添加新算法需要修改 OpenSSL 源码 Legacy 负担：过时的算法实现（如 MD5、DES）始终存在 OpenSSL 3.0 引入的 Provider 架构完美解决了这些问题。 Provider 架构概述 核心概念 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ┌─────────────────────────────────────────────────────┐ │ Application │ └──────────────────────┬──────────────────────────────┘ │ OSSL_DECODER / OSSL_ENCODER ┌──────────────────────▼──────────────────────────────┐ │ OpenSSL 3.0 Core │ │ ┌──────────────────────────────────────────────┐ │ │ │ Algorithm Fetch Layer │ │ │ │ (根据 Property Query 选择合适的 Provider) │ │ │ └──────────────────────────────────────────────┘ │ └──────────────────────┬──────────────────────────────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ ┌───────────────┐ ┌─────────────┐ ┌─────────────┐ │ Default Prov │ │ Legacy Prov │ │ FIPS Prov │ │ (默认算法集) │ │ (遗留算法) │ │ (合规算法) │ └───────────────┘ └─────────────┘ └─────────────┘ Provider 类型 OpenSSL 3....

在管理 SSL/TLS 证书和私钥时，你可能会遇到两种不同的私钥格式：PKCS#1 和 PKCS#8。本文详细介绍这两种格式的区别、使用场景以及转换方法。 什么是 PKCS#1 PKCS#1 是 RSA 加密标准的第一个版本，定义了 RSA 密钥的数学结构。其 PEM 格式的私钥文件头部为： 1 -----BEGIN RSA PRIVATE KEY----- PKCS#1 只支持 RSA 密钥，格式相对简单，直接存储 RSA 算法的参数（n, e, d, p, q 等）。 什么是 PKCS#8 PKCS#8 是通用的私钥格式标准，支持多种算法（RSA、EC、Ed25519 等）。其 PEM 格式的私钥文件头部为： 1 -----BEGIN PRIVATE KEY----- PKCS#8 使用更通用的结构，可以封装任意类型的私钥，并且支持加密存储。 格式对比 特性 PKCS#1 PKCS#8 PEM 头部 -----BEGIN RSA PRIVATE KEY----- -----BEGIN PRIVATE KEY----- 支持算法 仅 RSA RSA、EC、Ed25519 等多种算法 兼容性 旧版系统和应用 现代系统和应用（OpenSSL 1.0+） 生成与转换命令 生成 PKCS#8 格式私钥（默认） 1 2 3 4 5 6 7 8 # 生成 RSA 私钥（PKCS#8 格式，默认） openssl genrsa -out key....

在需要对加密操作进行合规性控制的场景中，FIPS 140-2（或 FIPS 140-3）是一个重要的标准。本文介绍如何在 OpenSSL 中启用和配置 FIPS 模式。 什么是 FIPS 140-2？ FIPS 140-2 是美国国家标准与技术研究院（NIST）发布的密码学模块安全要求标准。它定义了四个安全等级（Level 1-4），要求密码学实现经过严格测试和验证。 关键点： 强制要求在政府机构和受监管行业使用 OpenSSL 通过 FIPS 模块（OpenSSL-FIPS）提供支持 FIPS 模式开启后，仅允许使用经认证的加密算法 环境检查 首先检查当前 OpenSSL 版本： 1 openssl version -a 注意输出中的 FIPS 标记。如果显示 fips-mode 相关信息，说明已支持 FIPS。 安装 OpenSSL FIPS 模块 方法一：使用系统包管理器（推荐） Ubuntu/Debian： 1 2 sudo apt update sudo apt install openssl-fips RHEL/CentOS： 1 sudo yum install openssl-fips 方法二：从源码编译 1 2 3 4 5 6 7 8 9 # 下载 OpenSSL FIPS 模块源码（以 2....

ChaCha20-Poly1305 是 TLS 1.2 和 TLS 1.3 中广泛使用的 AEAD（带认证的加密）密码套件，尤其在移动设备上因性能优势被广泛采用。本文深入解析其加密原理及 OpenSSL 命令行实现。 1. 什么是 AEAD？ AEAD（Authenticated Encryption with Associated Data）同时提供： 机密性：通过加密保护数据隐私 完整性：通过 MAC（消息认证码）验证数据未被篡改 关联数据：可选择性地对未加密的元数据进行认证 常见的 AEAD 组合包括 AES-GCM、ChaCha20-Poly1305、ChaCha20-Poly1305-IETF。 2. ChaCha20 加密算法 2.1 算法概述 ChaCha20 是 Daniel J. Bernstein 于 2008 年设计的流密码算法，作为 Salsa20 的改进版本。其核心特点： 特性 说明 类型 对称流密码 密钥长度 256 位 Nonce 长度 96 位（12 字节） 块大小 512 位（64 字节） 迭代次数 20 轮（故名 ChaCha20） 2.2 加密原理 ChaCha20 使用**置换置换网络（PRP）**结构，将密钥、Nonce 和计数器混合生成 512 位的密钥流块： 1 2 ChaCha20(key, nonce, counter) → keystream blocks ciphertext = plaintext ⊕ keystream 核心操作包括：...

深入解析 TLS 1.3 握手摘要（Transcript）机制，以及 CertificateVerify 消息如何验证证书私钥所有权。

引言 CRYSTALS-Kyber 是 NIST 后量子密码学标准中的核心密钥封装机制（Key Encapsulation Mechanism, KEM），于 2024 年正式发布。作为 TLS 1.3 未来版本中 ECDHE 的潜在替代方案，理解 Kyber 的工作原理对于安全工程师至关重要。本文将深入解析 Kyber 的数学基础和工作流程。 1. 为什么需要后量子 KEM？ 传统 TLS 1.3 使用 ECDHE（椭圆曲线 Diffie-Hellman）进行密钥交换，其安全性基于有限域上离散对数问题的困难性。 量子计算机的 Shor 算法能在多项式时间内解决： 整数分解问题（RSA 密钥） 离散对数问题（ECDSA、ECDHE 密钥） 这意味着：一旦拥有足够大规模的量子计算机，当前基于 RSA 和 ECC 的密钥交换将不再安全。 后量子密码学（Post-Quantum Cryptography, PQC）应运而生——设计能够抵御量子攻击的经典算法。NIST 于 2024 年正式发布后量子密码学标准，CRYSTALS-Kyber 正是其中的核心算法。 2. 格理论基础 Kyber 的安全性建立在**格理论（Lattice-based Cryptography）**之上。 什么是格？ 格（Lattice）是 n 维空间中一组线性无关向量的整数线性组合。用数学语言描述： 给定 n 个线性无关的向量 b₁, b₂, …, bₙ ∈ ℝⁿ，格 L 是这些向量的所有整数线性组合的集合： 1 L = { Σᵢ aᵢbᵢ | aᵢ ∈ ℤ } 格困难问题 格密码学的安全性基于以下困难问题：...

openssl speed 是 OpenSSL 官方提供的加密算法性能基准测试工具。通过它可以了解不同加密算法在当前硬件上的处理速度，从而为生产环境选择合适的加密算法提供数据支撑。 基本用法 1 openssl speed [options] [algorithm...] 常用选项： -seconds N — 测试持续时间（默认 10 秒） -bytes N — 测试缓冲区大小（默认 16KB） -evp name — 使用 EVP 接口测试指定算法 -elapsed — 使用 wall-clock 时间而非 CPU 时间 -mr — 产生机器可读的输出 对称加密算法性能测试 测试 AES-256-GCM 1 2 3 4 5 6 7 8 9 10 $ openssl speed -seconds 1 -evp aes-256-gcm Doing AES-256-GCM for 1s on 16 size blocks: 1502986 AES-256-GCM's in 1....

漏洞概述 2026 年 1 月 27 日，OpenSSL 官方发布了安全公告，披露了一个高危漏洞 CVE-2025-15467。该漏洞位于 OpenSSL 的 CMS（Cryptographic Message Syntax）实现中，当处理使用 AEAD（Authenticated Encryption with Associated Data）密码的 AuthEnvelopedData 结构时，存在栈缓冲区溢出问题。 漏洞严重性评级为 High，可导致拒绝服务（DoS），在特定条件下甚至可能实现远程代码执行（RCE）。 影响版本 受影响的 OpenSSL 版本： OpenSSL 3.6.x OpenSSL 3.5.x OpenSSL 3.4.x OpenSSL 3.3.x OpenSSL 3.0.x 不受影响的版本： OpenSSL 1.1.1 OpenSSL 1.0.2 修复版本： OpenSSL 3.6.1 OpenSSL 3.5.5 OpenSSL 3.4.4 OpenSSL 3.3.6 OpenSSL 3.0.19 技术分析 CMS 简介 CMS（Cryptographic Message Syntax，RFC 5652）是一种用于签名、加密消息的通用语法标准，广泛应用于： S/MIME：安全电子邮件 PKCS#7：加密消息语法 代码签名 证书管理（如 CRL、证书请求） CMS 支持多种加密数据格式，包括： EnvelopedData：加密数据 SignedData：签名数据 AuthEnvelopedData：带认证的加密数据（AEAD） AEAD 密码与 AES-GCM AEAD（Authenticated Encryption with Associated Data）是一种同时提供机密性和完整性的加密模式。常见的 AEAD 密码包括：...