【密码学百科】密码学实现陷阱：三层漏洞分类、审计工具链与系统性预防

密码学算法在数学上可以做到无懈可击，但将它们转化为可执行代码的过程中，每一行源码、每一次编译器优化、每一个操作系统调度决策都可能打开一扇通往机密数据的暗门。历史反复证明：密码学工程中最危险的敌人不是算法本身的弱点，而是实现层面的疏忽。从 OpenSSL 的 Heartbleed 到苹果的 “goto fail”，从 Go 语言 P-521 椭圆曲线的归约错误到无数因时序泄露而被攻破的 HMAC 校验——几乎所有轰动业界的密码学安全事件，根源都在于代码而非数学。

然而，仅仅罗列这些事故并不足够。我们需要的是一套体系化的分类方法来理解漏洞发生在哪一层，一条完整的工具链来系统性地检测它们，以及一套可落地的流程来防止它们再次发生。本文正是围绕这三个维度展开：首先建立密码算法层、密码库层、系统集成层的三层漏洞分类框架；然后给出覆盖静态分析、模糊测试、形式化验证和依赖扫描的审计工具链；最后将经典案例从”出了什么错”转化为”什么流程能阻止它发生”。

一、三层漏洞分类框架

先看一张图，把这一节的关键关系串起来。

graph TD
    A[设计错误] --> B[API 误用]
    B --> C[实现缺陷]
    C --> D[部署配置问题]
    D --> E[真实漏洞]

密码学实现漏洞看似千变万化，但按照漏洞发生的抽象层次，可以清晰地划分为三层。这种分类不仅有助于理解每个漏洞的本质，更重要的是，它直接决定了应该使用哪类工具和流程来预防。

第一层：密码算法层

算法层漏洞是指在调用密码学原语时，由于对算法安全契约的误解而引入的错误。算法本身是正确的，但使用方式违反了安全假设。

典型漏洞模式：

1. 弱参数选择：使用过短的密钥（如 1024 位 RSA）、不安全的曲线（如 NIST P-192）或已被攻破的哈希函数（如 MD5、SHA-1 用于签名）。这类错误在部署时可能是安全的，但随着计算能力增长和攻击技术进步而变得脆弱。

2. Nonce/IV 重用：GCM 模式下 nonce 重用直接泄露认证密钥 H，使攻击者能伪造任意密文。CTR 模式下 IV 重用导致两段明文的异或值泄露。对于 96 位随机 nonce，在 2^32 条消息后碰撞概率已不可忽略。

3. 模式误用：使用 ECB 模式加密结构化数据（经典的”企鹅图”问题）；使用 CBC 模式但未配合 MAC（导致填充预言攻击）；使用 CTR 模式但未认证（密文可被按位篡改）。

4. 数学实现错误：椭圆曲线标量乘法中的进位处理错误、大数模归约中的边界条件遗漏。Go 语言 P-521 bug（CVE-2022-23806）即属此类——约每 2^64 次操作触发一次，常规测试几乎不可能发现。

预防原则： 算法层漏洞的核心预防手段是约束选择空间——使用抗误用 API（如 libsodium 的 crypto_secretbox，内部绑定了 XSalsa20 + Poly1305，无需用户选择模式）和经过形式化验证的数学实现（如 HACL*）。

第二层：密码库层

库层漏洞发生在密码学库的内部实现中，涉及 API 误用、内存安全和编译器交互等问题。即使算法选择完全正确，库层的一个 bug 就能摧毁全部安全性。

典型漏洞模式：

1. 时序侧信道：用标准库 memcmp 比较 HMAC 值，攻击者通过测量响应时间差异逐字节恢复 MAC，将 2^128 次暴力破解降为约 32768 次在线尝试。Brumley 和 Boneh 在 2003 年就通过网络远程时序攻击恢复了 OpenSSL RSA 私钥。

2. 缓冲区越界：Heartbleed（CVE-2014-0160）是最典型的案例——OpenSSL 心跳扩展实现中，使用攻击者声称的长度分配缓冲区并执行 memcpy，导致最多 64KB 的进程内存泄露。

3. 密钥材料残留：memset(key, 0, len) 被编译器的死存储消除优化删除，密钥在内存中长期驻留，可通过核心转储或冷启动攻击提取。

4. API 状态管理：OpenSSL 的 EVP_CIPHER_CTX 在重用时未调用 EVP_CIPHER_CTX_reset，前一次操作的 IV 和计数器残留到下一次操作中。EVP_DecryptFinal_ex 返回认证失败却被忽略，程序继续使用未认证的明文。

5. 编译器对抗：自动向量化将标量常量时间循环转为 SIMD 指令时引入数据相关的代码路径；链接时优化（LTO）跨翻译单元消除安全清零代码。

预防原则： 库层漏洞的预防依赖工具化检测——使用 dudect 和 ct-verif 验证常量时间性，用 AddressSanitizer 捕获内存错误，用编译器屏障对抗优化，通过代码审查确保 API 调用序列正确。

第三层：系统集成层

系统集成层漏洞出现在将密码学组件组装为完整系统的过程中，涉及协议实现、配置管理和运行时环境等问题。这一层的漏洞往往最难通过单元测试发现，因为它们通常只在组件交互时才会显现。

典型漏洞模式：

1. 协议逻辑错误：Apple “goto fail”（CVE-2014-1266）中，一行多余的 goto fail 跳过了 TLS 握手中的签名验证步骤，使任意证书都被接受。这不是算法错误，也不是库的 bug，而是协议流程的实现错误。

2. 证书验证缺失：OpenSSL 默认允许 SSL_connect 在证书验证失败时仍建立连接。2012 年的研究发现大量 Android 应用和 Java 库因未正确配置 SSL_VERIFY_PEER 而存在中间人攻击漏洞。

3. 降级攻击：TLS 版本协商中的逻辑缺陷允许攻击者强制使用弱协议版本或弱密码套件。POODLE 攻击（CVE-2014-3566）正是利用了 TLS 到 SSL 3.0 的降级路径。

4. 随机数生成器初始化：容器环境和虚拟机快照恢复场景中，RAND_bytes 可能在熵池未充分初始化时就被调用。如果开发者未检查返回值，就会使用低质量随机数生成密钥。Debian OpenSSL 事件（CVE-2008-0166）中，一个误删的代码行将熵源限制为进程 PID，导致两年内生成的所有密钥空间仅有约 32000 种可能。

5. 配置错误：生产环境中启用了调试模式导致密钥写入日志；TLS 配置允许了不安全的密码套件；未启用 HSTS 导致 HTTPS 降级。

预防原则： 系统集成层漏洞需要端到端测试和配置审计——使用协议模糊测试验证握手逻辑，用集成测试覆盖证书验证的各种失败路径，通过基础设施即代码（IaC）管理 TLS 配置，在 CI/CD 中集成配置扫描。

三层分类总览

二、密码算法层：常量时间编程与安全原语选择

时序侧信道的本质

当程序对机密数据执行分支跳转或表查找时，执行时间会随机密值的不同而产生可观测的差异。攻击者只需在网络另一端反复发送精心构造的请求，统计响应时间的微小波动，就能逐字节还原出密钥或消息认证码（MAC）。

常量时间比较与选择

标准库中的 memcmp 函数在发现第一个不匹配字节时立即返回，这使得攻击者可以通过时序差异逐字节恢复 MAC 值。正确的做法是遍历所有字节，用异或累积差异，最终一次性判断：

#include <stddef.h>
#include <stdint.h>

int secure_compare(const uint8_t *a, const uint8_t *b, size_t len)
{
    volatile uint8_t diff = 0;
    for (size_t i = 0; i < len; i++) {
        diff |= a[i] ^ b[i];
    }
    return (int)diff;  /* 返回 0 表示相等 */
}

类似地，根据秘密条件选择两个值之一时，不能使用三元表达式（编译器可能生成条件跳转），而应使用算术掩码：

uint32_t ct_select(uint32_t flag, uint32_t a, uint32_t b)
{
    uint32_t mask = -(uint32_t)flag;
    return (a & mask) | (b & ~mask);
}

常量时间编程的铁律是：所有依赖秘密数据的控制流和内存访问模式都必须消除。这意味着禁止对秘密值使用 if/switch/?:，禁止用秘密值作为数组下标（缓存时序泄露），对需要查表的操作使用位切片（bitsliced）实现。

抗误用 API：让正确使用成为唯一选择

NaCl/libsodium 代表了密码学 API 设计的范式转变。crypto_box 内部绑定了密钥协商（X25519）、对称加密（XSalsa20）和消息认证（Poly1305），开发者无需也无法选择模式或参数：

密文 = crypto_box(明文, nonce, 对方公钥, 我的私钥)

与之对比，OpenSSL 执行一次 AES-256-GCM 加密需要经历创建上下文、设置算法、配置 IV 长度、处理 AAD、处理明文、完成加密、提取标签等七个步骤，任何一步的遗漏或错序都可能导致静默的安全失败。

设计原则： 最安全的 API 不是功能最多的 API，而是最难被误用的 API。每增加一个选项，不是在”赋予用户更多能力”，而是在”增加用户犯错的维度”。

三、密码库层：内存安全与编译器对抗

密钥擦除与死存储消除

密钥在使用完毕后必须从内存中清除，然而 memset(key, 0, len) 在 -O2 及以上优化级别下几乎必然被编译器删除——C 标准允许编译器将无后续读取的写入视为死存储。

void process_key(const uint8_t *input)
{
    uint8_t key[32];
    derive_key(input, key);
    encrypt_with_key(key, ...);
    memset(key, 0, 32);  /* 编译器可能删除此行 */
}

正确的做法是使用 explicit_bzero（POSIX）、SecureZeroMemory（Windows）或基于 volatile 的跨平台实现：

void secure_memzero(void *ptr, size_t len)
{
    volatile unsigned char *p = (volatile unsigned char *)ptr;
    while (len--) {
        *p++ = 0;
    }
}

在更激进的链接时优化（LTO）场景下，还需要编译器屏障配合：GCC/Clang 使用 __asm__ __volatile__("" ::: "memory")，Rust 的 zeroize crate 结合了 write_volatile 和 compiler_fence，并通过过程宏自动为敏感结构体实现 Drop 清零。

内存保护纵深

libsodium 的 sodium_malloc 在分配的内存块前后各放置一个不可访问的保护页（guard page），越界读写立即触发段错误。释放时自动调用 sodium_memzero 清零，并将区域设为 PROT_NONE。结合 mlock 防止交换到磁盘，形成从分配到释放的完整防护链。

OpenSSL API 的典型陷阱

OpenSSL 是库层漏洞的高发区，以下模式在代码审计中反复出现：

• EVP 上下文重用：未在重用前调用 EVP_CIPHER_CTX_reset，GCM 模式下导致 IV 重用和认证密钥泄露。
• 错误检查缺失：EVP_DecryptFinal_ex 返回认证失败却被忽略，程序继续使用未认证的明文。
• 线程安全：OpenSSL 1.0.x 需要用户注册线程锁回调，否则多线程使用导致内存腐败。
• 证书验证默认值：SSL_connect 默认不验证证书，必须显式设置 SSL_VERIFY_PEER。

四、系统集成层：协议实现与配置安全

协议逻辑的脆弱性

系统集成层的漏洞往往不是某个函数的 bug，而是控制流的错误。Apple “goto fail” 是最典型的例子——一行重复代码跳过了 TLS 签名验证的关键步骤：

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;  /* 多余的一行——无条件跳转，跳过签名验证 */
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

这个漏洞不在算法层（SHA-1 运算本身正确），不在库层（SecureTransport 的密码学原语工作正常），而完全在系统集成层——协议握手流程的实现逻辑出了问题。

配置层面的系统性风险

生产系统中的配置错误是系统集成层最常见的漏洞来源：

• TLS 密码套件白名单：允许了已知不安全的套件（如 RC4、EXPORT 级别密码）。
• 证书链验证：未配置完整的中间 CA 证书链，或未启用 OCSP stapling 检查吊销状态。
• HSTS 缺失：未设置 HTTP Strict-Transport-Security 头，允许 HTTPS 降级到 HTTP。
• 密钥轮换：密钥长期不轮换，增加了密钥被攻破后的影响范围。

运行时环境的陷阱

容器化和虚拟化环境引入了新的系统集成层风险。虚拟机快照恢复后，内存中的随机数生成器状态被回退，可能产生重复的随机数。容器快速启动时熵池可能不充分。这些问题无法通过密码学库本身解决，需要在系统层面配置 virtio-rng 等硬件随机数源，或在应用启动时显式检查熵池状态。

五、系统性审计流程与工具链

理解了三层漏洞分类之后，核心问题变成了：如何系统性地检测和预防这些漏洞？逐项对照清单式的审计效率低且容易遗漏。本节给出一条覆盖从代码编写到持续运行的完整工具链。

阶段一：静态分析——在代码合入前拦截

静态分析工具在不执行代码的前提下扫描源码，能在 CI/CD 流水线中自动拦截已知的漏洞模式。

Semgrep 适合编写自定义密码学规则。以下规则检测 Go 代码中使用不安全的 math/rand 而非 crypto/rand：

rules:
  - id: insecure-random
    patterns:
      - pattern: math/rand.$F(...)
    message: "使用 crypto/rand 替代 math/rand 生成密码学相关随机数"
    severity: ERROR
    languages: [go]

Semgrep 还可以编写规则检测 memcmp 用于 MAC 比较、ECB 模式使用、缺少 SSL_VERIFY_PEER 设置等模式。

CodeQL 提供更强大的数据流分析能力，适合追踪复杂的漏洞模式：

import cpp

from FunctionCall fc
where fc.getTarget().hasName("memcmp")
  and exists(FunctionCall mac |
    mac.getTarget().hasName("HMAC") and
    DataFlow::localFlow(DataFlow::exprNode(mac), DataFlow::exprNode(fc.getArgument(0)))
  )
select fc, "HMAC 输出不应使用 memcmp 比较——存在时序侧信道风险"

CodeQL 的优势在于能够追踪数据从密码学函数的输出到比较操作的完整流路径，减少误报。

审计优先级： 静态分析应首先覆盖 P0 级别的模式——时序侧信道和 nonce 重用。这两类漏洞即使在正确使用成熟密码库的前提下仍极易发生。

阶段二：动态测试——模糊测试与运行时检测

静态分析无法发现所有问题，尤其是依赖运行时状态的漏洞。动态测试通过实际执行代码来发现问题。

覆盖引导 Fuzzing（libFuzzer / AFL） 自动生成大量变异输入，监控代码覆盖率，逐步穿透输入校验到达深层逻辑。配合 AddressSanitizer（ASan）和 MemorySanitizer（MSan），能捕获缓冲区溢出、未初始化内存读取等问题。libFuzzer 与 Clang 紧密集成，每秒可执行数十万次测试。

差异 Fuzzing 对密码学代码尤其有价值：对同一输入分别用两个独立实现处理（如 OpenSSL 与 BoringSSL），比较输出是否一致。Go P-521 bug 正是通过差异 Fuzzing 发现的——常规测试无法触发的约 2^64 分之一概率的数学错误，在数十亿次自动化测试中暴露了出来。

时序侧信道检测 使用 dudect 工具，它基于统计假设检验判断函数执行时间是否依赖于输入值。ct-verif 则在 LLVM IR 层面静态验证常量时间性质，不依赖运行时测量。

持续 Fuzzing 基础设施： Google 的 OSS-Fuzz 为开源项目提供 7x24 的 fuzzing 服务。OpenSSL、BoringSSL、libsodium、NSS 等主要密码学库均已接入。将自身项目接入 OSS-Fuzz 或在 CI 中集成 Fuzzing 回归测试，是系统性预防库层漏洞的关键措施。Project Wycheproof 提供了大量针对已知实现陷阱的边界测试向量，应作为 Fuzzing 种子库使用。

阶段三：形式化验证——数学级别的正确性保证

代码审计和测试本质上是抽样检验，无法证明不存在 bug。形式化验证通过数学证明确保代码在所有可能输入下的正确性。

**HACL*/EverCrypt**（微软 Project Everest）使用 F* 依赖类型语言编写密码学库，验证功能正确性、内存安全和秘密独立性（常量时间）三重性质。HACL* 的代码通过 KreMLin 提取为 C 代码，已被 Firefox 和 Linux 内核采用。

SAW（Software Analysis Workbench） 和 Cryptol 是 Galois 开发的工具链。Cryptol 用于编写密码学算法的可执行规约，SAW 将规约与 C/Java/LLVM 实现进行等价性验证。典型工作流程：

1. 用 Cryptol 编写算法的参考规约（与数学定义一一对应）。
2. 用 SAW 证明 C 实现与 Cryptol 规约在所有输入下等价。
3. 任何不等价都意味着实现偏离了规约——要么是 bug，要么是规约需要更新。

Jasmin/EasyCrypt 路线允许开发者以接近汇编的控制力编写代码，同时用 EasyCrypt 进行游戏序列（game-based）安全性证明。Jasmin 编译器保证编译结果语义等价。

形式化验证的定位： 验证成本约为未验证代码的 5-10 倍，因此应聚焦于最关键的底层密码学原语，而非上层应用代码。算法层和库层的核心代码适合形式化验证，系统集成层更适合 Fuzzing 和集成测试。

阶段四：依赖扫描与持续监控

即使自身代码无漏洞，依赖的密码学库可能包含已知漏洞。依赖扫描是系统集成层防御的重要一环。

• Dependabot / Renovate：自动监控依赖库的 CVE 披露，生成升级 PR。
• cargo audit（Rust）/ npm audit（Node.js）/ pip-audit（Python）：语言生态的专用依赖审计工具。
• SBOM（软件物料清单）：维护密码学依赖的完整清单，一旦某个库披露漏洞，可以立即确定影响范围。
• 废弃算法扫描：定期扫描代码库中 MD5、SHA-1（用于签名）、RC4、DES、EXPORT 级别密码套件等已废弃算法的使用。

审计工具链总览

六、案例分析：从”出了什么错”到”怎样防止再次发生”

Heartbleed（CVE-2014-0160）——密码库层漏洞

事故回顾。 2014 年 4 月披露的 Heartbleed 位于 OpenSSL 的 TLS 心跳扩展实现中。心跳协议允许一端发送数据和长度字段，另一端原样返回。OpenSSL 使用攻击者声称的长度分配缓冲区，未做边界检查：

/* 漏洞代码（简化） */
unsigned int payload_length = msg->length;  /* 攻击者控制 */
unsigned char *reply = OPENSSL_malloc(1 + 2 + payload_length + padding);
memcpy(reply, msg->data, payload_length);   /* 越界读取！ */

攻击者发送声称长度 65535、实际载荷为空的请求，即可读取进程内存中最多 64KB 的数据，可能包含私钥、会话密钥、用户密码等敏感信息。

漏洞分类：密码库层。 这是库内部的缓冲区越界读取，与算法选择无关，也非协议逻辑错误。OpenSSL 的自定义内存分配器（OPENSSL_malloc 使用自己的空闲列表）阻止了操作系统级保护机制发挥作用。

什么流程能阻止它：

1. Fuzzing + ASan（可直接捕获）：对心跳扩展的输入解析函数运行 libFuzzer 并启用 AddressSanitizer，越界读取会在第一次触发时立即被 ASan 报告为 heap-buffer-overflow。这是最直接的检测手段。
2. 静态分析（可标记风险）：CodeQL 的污点分析规则可以追踪从 msg->length（不可信来源）到 memcpy 长度参数的数据流，标记”外部输入直接控制内存操作长度”的高风险模式。
3. 内存安全语言（可根本消除）：如果使用 Rust 等内存安全语言实现，编译器会在编译期拒绝未经边界检查的内存访问。BoringSSL 和 LibreSSL 正是 Heartbleed 催生的”清理重写”项目。
4. 代码审查（应当发现但未能发现）：该 bug 在代码库中存在了两年。根本原因是心跳扩展被视为”不重要的辅助功能”，未得到与核心加密逻辑同等的审查力度。教训：密码学库中的每一行处理网络输入的代码都应按最高安全级别审查。

Go 语言 P-521 椭圆曲线 Bug（CVE-2022-23806）——密码算法层漏洞

事故回顾。 2022 年，Go 标准库的 P-521 椭圆曲线实现被发现在模归约时未正确处理特定的进位情况，导致极少数情况下（约 2^64 次操作触发一次）标量乘法结果出错。该漏洞可能导致 ECDSA 签名验证绕过或 ECDH 密钥协商生成弱共享密钥。

漏洞分类：密码算法层。 这是数学实现中的边界条件错误，与库的 API 设计或系统集成无关。

什么流程能阻止它：

1. 差异 Fuzzing（实际发现者）：将 Go 的实现与另一个独立实现（如 OpenSSL 或 HACL*）进行对比测试，在数十亿次随机输入中发现了不一致的输出。这正是该漏洞的实际发现方式。
2. 形式化验证（可根本消除）：使用 SAW 将 Go 的大数运算代码与 Cryptol 参考规约进行等价性验证，进位处理中的偏差会被证明器精确定位。HACL* 的 P-256 实现正是通过这种方式确保了数学正确性。
3. Wycheproof 测试向量（可部分覆盖）：Google 的 Wycheproof 项目包含了针对椭圆曲线边界条件的测试用例，但对于触发概率仅 2^-64 的错误，预设测试向量的覆盖率有限，仍需依赖大规模 Fuzzing。
4. 修复后的改进：Go 团队在修复后引入了与 HACL* 参考实现的交叉验证，并将差异 Fuzzing 纳入持续集成，确保类似错误不再遗漏。

Apple “goto fail”（CVE-2014-1266）——系统集成层漏洞

事故回顾。 2014 年 2 月，苹果的 SecureTransport 中发现一行多余的 goto fail 跳过了 TLS 握手中签名验证的关键步骤，使攻击者可用任意证书进行中间人攻击。

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;  /* 多余的一行——无条件跳转，跳过签名验证 */
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

漏洞分类：系统集成层。 密码学原语（SHA-1 运算）工作正常，库的 API 也无问题，错误在于 TLS 协议握手流程的实现逻辑。

什么流程能阻止它：

1. 编译器警告（最简单的检测）：Clang 的 -Wunreachable-code 会标记第二个 goto fail 之后的死代码。在 CI 中启用 -Werror 将此类警告升级为编译错误，即可在代码合入前自动拦截。
2. 静态分析（可直接捕获）：Semgrep 或 CodeQL 可以编写规则检测”不在条件语句控制下的 goto”模式，或更广泛地检测”if 语句体未使用花括号且紧随多条语句”的代码风格问题。
3. 集成测试（应当覆盖）：使用无效证书链的 TLS 连接测试——如果测试中包含”服务器提供自签名证书时客户端应拒绝连接”的用例，bug 会立即暴露。覆盖 TLS 验证的正向和反向路径是协议测试的基本要求。
4. 协议 Fuzzing（系统性检测）：TLS 协议模糊测试工具（如 tlsfuzzer）生成各种畸形握手消息和无效证书链，系统性地覆盖协议状态机的各个分支。
5. 代码风格强制（根本预防）：强制所有 if 语句体使用花括号——如果当初使用了花括号，重复的 goto fail 就不会导致安全问题。

三案例预防矩阵

七、密码学代码审计方法论

以密钥生命周期为主线

逐项对照审计清单效率低且容易遗漏。更有效的方法是沿着密钥材料的完整生命周期进行审查——生成、存储、使用、销毁四个阶段。密钥是密码系统的”血液”，追踪它的流向就是追踪整个系统的安全边界：

• 生成：随机数源是否使用了 CSPRNG？熵池是否在应用启动时充分初始化？容器/虚拟机环境中是否配置了硬件熵源？
• 存储：密钥是否明文写入磁盘？是否可能出现在日志、错误消息或核心转储中？是否通过 mlock 锁定以防止换页？
• 使用：同一密钥是否被用于不同上下文（密钥分离是否充分）？nonce 管理是否正确？MAC 验证是否使用常量时间比较？
• 销毁：是否使用了 explicit_bzero 或等价原语？编译器是否可能将清零优化掉？

优先级驱动的审计排序

基于风险影响和发生频率，以下是审计的优先级排序：

将审计嵌入开发流程

审计不应是一次性事件，而应嵌入到日常开发流程中：

1. PR 合入前：CI 运行 Semgrep/CodeQL 密码学规则集，编译器启用 -Wall -Werror。
2. 每日构建：持续 Fuzzing 回归测试，差异 Fuzzing 与参考实现对比。
3. 版本发布前：Dependabot 扫描依赖 CVE，废弃算法审计，TLS 配置扫描。
4. 季度审查：密钥生命周期完整审查，形式化验证更新（如有），威胁模型更新。

个人思考。 “不要自己实现密码算法”（Don’t roll your own crypto）是密码学工程中流传最广的忠告，但也是最容易被曲解的。现实中绝大多数密码学漏洞不是有人从零写了一个 AES——而是有人在调用 OpenSSL 或 libsodium 时犯了 nonce 重用、忘记验证认证标签、用 memcmp 比较 HMAC 这样的错误。真正的工程忠告应该是：不要自己实现密码算法，同时也不要以为用了好的库就万事大吉——你需要理解你在调用的每一个 API 的安全契约，并用工具链系统性地验证这些契约没有被违反。

密码学百科系列 · 第 29 篇

← 上一篇：侧信道攻击 | 系列目录 | 下一篇：密码敏捷性 →