第3章 密钥生成中的边界问题

说到密钥生成，很多人第一反应是“随机数够不够随机”。但我在实际排查中发现，真正翻车的往往不是随机性，而是边界。你想想看，一个密钥生成函数，传入的参数稍微偏了一点，出来的密钥可能整个结构都变了——或者更糟，结构没变但熵没了。

这一章我们专门聊聊密钥生成里的边界问题。我个人习惯把这类问题叫做“车道线偏移”——明明在车道里开，但压了线，事故就在那一瞬间。

密钥生成边界问题排查逻辑 密钥生成参数输入 边界值检查（长度/编码/范围） 边界值遗漏 长度=0 / 长度=256 运算边界溢出 整数溢出 / 下标越界 隐式截断 类型转换 / 位数丢失 密钥结构损坏 / 熵降低 安全性归零，可直接被攻破 排查顺序 先查边界检查 → 再查运算溢出 最后查截断/隐式转换

3.1 边界值问题：最容易被忽视的漏洞

边界值问题是什么？说白了就是参数的“临界点”没处理好。比如密钥长度要求是 16~32 字节，那么 16 和 32 本身就是边界，小于 16 和大于 32 是越界。但我碰到过的案例，往往是边界上的值反而没被覆盖测试。

现场还原：

  • 一个密钥派生函数，要求输入盐值长度在 8~64 字节之间
  • 代码里写了 if len(salt) > 64: return error
  • 但没写 if len(salt) < 8: return error
  • 结果有人传了空盐，函数直接用了默认空值，派生出的密钥等于没加盐

为什么会出现这种遗漏？我见过太多类似的错误了——开发者的大脑天然倾向于检查“过大”，却容易忽略“过小”。还有个常见病是只检查了上限没检查下限，或者上下限检查了但 等于边界 的情况被错误放行。

关键点：边界值检查必须包含 == 情况。比如长度 0 是不是允许？长度刚好等于最大值时缓冲区会不会溢出？我曾经在审计一个金融 API 时发现，密钥生成函数允许长度=256，但内部缓冲区只开了 255，导致每次生成 256 位密钥时都会写越界一个字节。这个 bug 在生产环境跑了两年，直到我们做压力测试才触发。

3.2 边界溢出：整数运算的暗坑

这一节我要重点说说整数溢出导致的密钥边界问题。你可能会觉得“整数溢出在密码学里很罕见吧？”——实际上我遇到过不止一次。

看这个典型的错误写法：

// 计算密钥缓冲区大小
int key_size = user_input_length + padding;
// 假设 user_input_length 来自外部，padding 固定 16
// 如果 user_input_length = 0xFFFFFFFF，那么 key_size = 0xFFFFFFFF + 16 = 15（溢出环绕）
char *key_buf = malloc(key_size);
// 实际分配了 15 字节，但后续写入超过 15 字节，堆溢出

这不是编的。我在某云厂商的 SDK 里确实见到过类似代码——密钥生成前做了边界检查，但检查的是输入长度，而不是计算后的长度。检查输入长度在 0~255 通过，但加上 padding 后溢出了，malloc 申请到一个很小的缓冲区，后续 memcpy 就直接写穿了。

我的修复习惯：

  1. 所有涉及长度的运算，必须用 size_t 无符号类型
  2. 在加法/乘法前先判断是否会溢出：if (a > SIZE_MAX - b) return error;
  3. 最终检查：分配后的内存大小必须 再次确认 与实际写入大小一致

还有一种溢出更隐蔽——循环中的下标越界。比如生成密钥时逐字节填充：

for (int i = 0; i <= key_length; i++) {
    key[i] = random_byte();
}
// 等号是错的！i 会跑到 key_length，而数组下标最大是 key_length-1
// 多写了一个字节，覆盖了相邻内存

这种问题在代码审查时特别容易被忽略。你想想看，<= 和 < 就差一个等号，但造成的后果可能是灾难性的——覆盖掉的可能是另一个密钥数据、控制结构，甚至是函数返回地址。

3.3 边界截断：隐式转换的陷阱

边界截断问题在 C/C++ 和 Java 里特别常见。说白了就是数据在赋值或传参时被悄悄地切掉了一部分。

我遇到过的一个真实案例：

场景：一个硬件安全模块（HSM）的密钥生成接口

  • 接口定义：int generate_key(int key_id, unsigned char *key_out, unsigned int key_len)
  • 调用方传入 key_len = 256（单位是字节）
  • 内部实现：unsigned char local_key[256];
  • 问题出在——内部用一个 uint8_t 来接收 key_len，uint8_t max_len = key_len;
  • 256 转换成 uint8_t 后变成了 0，后续循环直接没有执行
  • key_out 里全是栈上垃圾数据，但接口返回了成功

这就是典型的隐式截断。你传进去的数据被类型系统“咬”了一口。这类问题在密钥生成中的破坏力尤其大——它不会让你的程序崩溃，但会给你一个完全不可预测的“密钥”。我后来在这个 HSM 上做测试时发现，传入长度 256 时输出的是栈遗留数据，这比一个固定密钥还危险——攻击者如果能控制栈布局，甚至能预测这个“密钥”。

避坑指南：我曾经养成一个习惯——所有密钥长度相关的参数，在函数入口处做一次显式检查：

  • 检查参数类型范围是否够用（int 到 uint8_t 会截断）
  • 检查长度是否在预期范围内（0~255 或 0~65535）
  • 检查转换后的值是否与原始值一致

3.4 BOUNDARY_CHECK 常量：一个被低估的设计

我在内部培训时经常提到一个概念——BOUNDARY_CHECK 常量。它不是语言特性，而是一种编码约定：

#define MAX_KEY_LENGTH 64
#define MIN_KEY_LENGTH 16

// 不要写魔法数字
if (len > 64) return ERROR;  // ❌ 64 为什么是 64？哪来的？

// 应该用常量
if (len > MAX_KEY_LENGTH || len < MIN_KEY_LENGTH) return ERROR;  // ✅

这不仅是代码可读性的问题——我来告诉你为什么它对边界问题排查特别重要：

写法排查难度修改风险典型后果
魔法数字 32高（不知道 32 是什么边界）高（改了 32 可能影响其他逻辑）边界不一致，密钥生成和验证不同步
常量 MAX_IV_LENGTH低（名字说明用途）低（改一处即可）统一管理，减少遗漏
配置项 config.max_key_len中（需要查配置来源）中（配置可能被外部覆盖）线上配置错误导致密钥生成失败

我个人强烈建议密钥相关的边界常量使用统一的头文件管理，并且加上单元测试来验证这些边界值本身是否正确。我曾经就碰到过 MIN_KEY_LENGTH 定义成了 32 但实际算法只支持 16~32 的情况，结果传入 16 时通过检查但内部计算却失败了——这就是边界常量与算法实现不一致的典型。

3.5 经验总结：边界问题排查清单

最后给一份我在项目里实际使用的排查清单，希望能帮你少走弯路：

密钥生成边界问题快速排查清单：

  1. 检查输入参数的长度范围：下限、上限、等于边界的情况
  2. 检查中间运算是否会溢出：加法/乘法/位移操作
  3. 检查类型转换是否有截断：int→short→char 每步都可能丢数据
  4. 检查循环条件：<= 还是 <，数组下标不要越界
  5. 检查缓冲区分配：分配后的大小是否真的够用
  6. 检查返回值路径：边界异常时是否返回了错误码（而不是部分结果）
  7. 检查边界常量的定义：是否与算法文档一致

边界问题在密钥生成里尤其致命，因为它往往不会立即报错。你可能会得到一个看起来正常的密钥，但放到实际加解密里就是解不开。或者更糟——解开一部分，给你一种“好像对了”的错觉。我处理过的几个生产事故，都经历了“能用→偶尔失败→彻底不可用”这样一个逐步恶化的过程，根因都出在边界上。

嗯，边界问题说到这里就差不多了。记住一句话：密钥生成的每一行代码，都要想想“如果这个参数正好在边界上，会发生什么？”——这个习惯，救过我很多次。

← 上一章 📖 返回目录 下一章 →