📚 课程目录第4章密钥生成边界条件

4. 密钥生成边界条件：随机数熵源、密钥长度合规性检测归纳总结

密钥生成，说白了这个环节是国密算法安全的第一道防线。你密钥如果生成得不好，后面所有加密、签名、密钥协商全是摆设。我在好几个项目里都见过因为随机数熵源不足或者密钥长度没对齐而导致的安全事件。这一章咱们就把这两个边界条件拆开揉碎了讲清楚。

4.1 随机数熵源：别让密钥变成“伪随机”

随机数熵源的质量直接决定了密钥的不可预测性。我当初做智能卡安全评估时，遇到过一个案子——某款金融终端用的随机数发生器其实是个线性反馈移位寄存器，种子还写死在固件里。结果同一个批次所有设备的会话密钥都一样，攻击者拿到一台就能解密整个网络的流量。嗯，这就是典型的熵源失效。

4.1.1 熵源的物理来源与采集方式

国密标准（GM/T 0005、GM/T 0062）明确要求随机数生成器必须具有物理熵源。常见的来源有这些：

热噪声熵：利用半导体PN结的散粒噪声或电阻热噪声，采集模拟信号再量化。稳定，但采样速率慢。
环形振荡器抖动：多个反相器环的相位抖动，通过比较多个环的采样值提取熵。我在FPGA上常用这个方案。
亚稳态采样：利用触发器在建立/保持时间违规时的输出不确定性。面积小，但需要后处理去偏。

注意，软件伪随机数（如C语言的rand()）不能用。哪怕用了/dev/random，你也得确认操作系统底层是否真的挂了硬件熵源。

4.1.2 熵源质量的量化指标

指标	含义	国标要求	我碰过的坑
最小熵	最坏情况下每个输出比特的不可预测度	≥0.5 bit/采样	某款芯片标称0.8，实测只有0.2
自相关函数	序列相邻位之间的相关性	滞后1~10内相关系数＜0.01	我用MATLAB跑完自相关才发现有周期性
NIST SP 800-22 测试	15项统计检测（频数、游程、块内频数等）	全部通过	频率测试经常挂，后来发现是熵源混入了时钟干扰
GM/T 0005 附录B要求	中国国家密码管理局对随机数发生器的详细测试	必须满足	这个附录的测试向量很刁钻，我调了三个月

警告：熵源健康状态需要实时监控。我曾经遇到过一款产品，上电半小时后因为温度变化导致环形振荡器抖动变小，随机数质量急剧下降。硬件设计时必须加在线自检，一旦检测到异常就停止密钥生成并上报。

4.1.3 后处理与脱偏

原始熵源不一定均匀分布，需要用后处理算法来“洗白”。常用的有：

冯·诺依曼纠正器：针对相邻比特对，丢弃“00”“11”保留“01”“10”。简单但吞吐量低一半。
哈希蒸馏：用SM3或SHA-256对熵源输出做压缩。吞吐量高，且能把任意偏置的比特流变成均匀分布。我个人偏好SM3，因为国密合规。
LFSR后处理：线性反馈移位寄存器，但要注意不能过度依赖它——它本质是确定的，不能弥补熵源本身的不足。

小技巧：在FPGA上实现SM3哈希蒸馏时，建议先把熵源数据缓存到FIFO，然后一口气喂给SM3核。这样既保证吞吐率，又避免时序紧张导致漏采。

4.2 密钥长度合规性检测：别让密钥“太短”或“太长”

国密算法对密钥长度有严格规定。SM2（椭圆曲线）的密钥长度是固定的——256比特（32字节）。SM4的分组密钥是128比特（16字节）。SM3（哈希，虽然不叫密钥但同样有长度边界）的摘要长度是256比特。

但实际工程中，你接收到的密钥可能来自不同来源：手动输入、硬件接口、通信协议。长度不符就出大问题。我见过一个典型bug：某厂商的密钥管理系统把SM2私钥当128字节存储，结果签名模块读出来取前32字节，剩下的96字节被截断了。签名还总过不了验证，最后发现是长度检测没做。

4.2.1 密钥长度检查清单

SM2公钥：压缩形式33字节（02/03 + 32字节x坐标），非压缩形式65字节（04 + 32x + 32y）。注意压缩格式的标识符不能错。
SM2私钥：32字节大端无符号整数。必须检查是否在[1, n-1]范围内（n为SM2椭圆曲线阶）。我曾经自己写过一个测试，发现随机生成的私钥有0.5%概率等于0或大于n-1，必须排除重生成。
SM4密钥：16字节。注意有些协议会用ASCII字符串作为密码，然后通过KDF变换成密钥——那KDF输出的长度必须是16字节，不能多或少。
SM3摘要：32字节。如果上层应用要求128比特（如HMAC-SM3的密钥长度可伸缩），那需要SM3先对密钥做一次摘要来固定长度。

算法	密钥长度（字节）	必须检查的范围	常见合规性问题
SM2公钥	33 / 65	首字节为02/03或04	非压缩格式首字节误写成0x00
SM2私钥	32	1 ≤ d ≤ n-1	未检查范围，导致后续签名生成非法值
SM4	16	无特殊范围，但必须精准16	从随机数生成器取了64字节直接用
SM3（作为密钥输入）	任意→32（经压缩）	预处理后必须是32字节	直接用不定长字符串当摘要

  核心原则：所有密钥生成接口在输出前，必须做一次“合规性三重确认”——长度匹配、范围有效、格式正确。这三项任何一项没通过，直接拒绝输出并报错，绝不能静默截断或填充。

4.3 随机数熵源与密钥长度的交互边界

有些人觉得熵源质量和密钥长度是两码事。其实不然。举个例子：熵源每秒钟提供128比特的随机数，但你需要生成一个SM2密钥对（私钥32字节 = 256比特）。如果熵源输出速率跟不上，你不能重复读取相同的熵值填充剩余位数——那会让密钥有可预测性。

我在设计一个IoT安全芯片时遇到过这个场景：硬件熵源只有2MHz采样率，每次采样能提取0.5比特最小熵。要生成256比特的SM2私钥，至少需要512次采样，耗时256微秒。如果系统要求密钥生成延迟在100微秒以内，那就得并行用4路熵源或者预缓存熵池。否则就会出现“假随机”——为了赶时间读取未完全更新的熵池数据。

边界条件总结：

熵源输出速率 × 每个采样最小熵 ≥ 密钥所需比特数 / 允许的密钥生成时间
如果不够，要么升级熵源硬件（比如改用热噪声芯片），要么允许更长的生成时间。你不能在后处理里“扩充”熵——那叫确定性扩展，不是真随机。

4.4 代码示例：带合规性检测的SM2密钥生成

下面是我在实际项目中用C语言写的SM2密钥生成片段，重点展示边界检查：

// 假设已有函数：entropy_get_bytes(uint8_t *buf, size_t len, int *ok)
// 返回0表成功，-1表熵源失效

int sm2_gen_keypair(sm2_keypair *kp) {
    uint8_t rand_buf[32];
    int ret, ok;
    
    // 步骤1：从熵源获取256比特随机数
    ret = entropy_get_bytes(rand_buf, 32, &ok);
    if (ret != 0 || ok != 1) {
        // 熵源异常
        return -1;
    }
    
    // 步骤2：将字节转换为大端整数
    // 注意：必须确保d在[1, n-1]内
    // 实际实现通常使用BN库，这里简化演示
    uint64_t d = 0;
    for (int i = 0; i < 32; i++) {
        d = (d << 8) | rand_buf[i];
    }
    // SM2曲线阶 n = 0xFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFF7203DF6B21C6052B53BBF40939D54123 (256bits)
    // 假设已有函数 is_valid_range(d)
    if (!is_valid_range(d)) {
        // 重新生成
        goto retry;
    }
    
    // 步骤3：计算公钥点
    // ... (省略椭圆曲线点乘)
    
    // 步骤4：输出前再检查长度
    assert(sizeof(kp->private_key) == 32);
    memcpy(kp->private_key, rand_buf, 32);
    // 公钥格式检测（非压缩：65字节）
    assert(kp->public_key[0] == 0x04);
    
    return 0;
}

提示：上面的retry循环不能无限重试。我一般限制最多3次，防止熵源持续异常导致死循环。3次后返回错误，让上层知道熵源可能已经挂了。

4.5 本章知识体系图

4.6 避坑指南与经验总结

我曾经踩过的坑：在一个国密网关项目中，我们使用硬件安全模块（HSM）生成SM2密钥对。HSM内部有自己的熵源，但接口文档没写熵源健康状态位的读取方式。结果运行半年后，某台HSM的熵源因为老化导致输出熵值偏低，但HSM依然返回“成功”状态。签名质量逐渐下降，最终被攻击者通过侧信道分析恢复了部分私钥。从那以后，我强制要求所有密钥生成接口必须返回熵源健康指数和最后一次合规检测的时间戳。

个人习惯：我现在设计密钥生成模块时，会单独封装一个“边界条件仲裁器”——它负责收集熵源状态、密钥长度、范围标志、后处理参数，然后综合判断能否输出密钥。这个仲裁器会在日志里记录每一次仲裁结果，方便事后审计。

熵源：必须硬件物理，必须实时健康监控，必须通过国密检测。
密钥长度：每个算法都有固定长度，不能“差不多”。范围检测（尤其是SM2私钥）不能省。
交互边界：熵源输出速率与密钥长度的乘积必须满足实时性要求。不满足就改硬件或放宽时间，不能妥协熵质量。
代码层面：三重确认 + 重试限制 + 错误上报，三者缺一不可。