1. 知识点为什么密码学需要KAT 红线普通工程代码可以看起来对 边界测试过就发布。密码学不行错一位就是整体失效哈希/加解密是雪崩式的一个常量抄错输出跟标准毫无相似度但看起来很随机——靠人眼根本验不出来标准答案免费可得GM/T 0004SM3等标准附录给了官方向量如SM3(abc) 66c7f0f4…。把这些向量写进自检等于给实现装了出厂校准——先有答案再写实现红线要能隔离理想的自检是哪个原语错就哪个红而不是一团 FAIL 让你猜——所以 KAT 要按原语分组跑。引擎的源码注释vllm_crypto.c4–5 行把这条纪律写得很直白位级正确性由独立测试驱动用国密标准 KAT 向量逐字节验证red line。文档进一步说明该驱动vllm_crypto_test.c未随仓库分发权重保护与可验证推理方案 224 行——本日我们自己搭最小 harness把这条红线在板上立起来。2. 对应代码最小 KAT harnesscrypto_kat.c对着vllm_crypto.h的公开 API写一个零依赖 harness验证四件事vc_sm3(abc, 3, d) → 与 66c7f0f4… 对拍SM3 官方向量 vc_sm3(, 0, d) → 与 1ab21d83… 对拍空串向量 vc_sm3 分块输入361 字节喂 update→ 与 abcd*16 的 64B 向量对拍走填充缓冲路径 vc_sm4_setkey_enc crypt_block → 与标准单块向量 681edf34… 对拍 vc_sm2_sign/verify → 功能回环 篡改 r 后必须验不过编译方式板端与引擎同一份vllm_crypto.cgcc -O2 -Irepo/include -Irepo/include/common \ crypto_kat.c repo/src/common/vllm_crypto.c -o crypto_kat -lm3. 改动后果板端 KAT 实测——红线为什么是红线实测口径RK3588 / aarch64 / 2026-09-07 / gcc -O2。原始实现 [PASS] SM3(abc) 66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0 [PASS] SM3() 1ab21d8355cfa17f8e61194831e81a8f22bec8c728fefb747ed035eb5082aa2b [PASS] SM3(64B abcd*16, 361) debe9ff92275b8a138604889c18e5a4d6fdb70e5387e5765293dcba39c0c5732 [PASS] SM4-ECB KAT (block) [PASS] SM2 sign/verify roundtrip [PASS] SM2 tamper rejected (r ! r) KAT: ALL PASS (red line green) 篡改后把 SM3_IV[0] 的 0x7380166f 改成 0x7380166e其余不动 [FAIL] SM3(abc) 7a3773dc0de682e8…与标准无一位相同 [FAIL] SM3() 1d6d2431… [FAIL] SM3(64B, 361) 8dfe48ba… [PASS] SM4-ECB KAT (block) ← 不受影响 [PASS] SM2 sign/verify roundtrip ← 不受影响 KAT: FAILURES PRESENT三个教训一个十六进制位 输出全变0x7380166f → 0x7380166e只是 IV 最低位 -1三个 SM3 输出立刻与标准毫无相似度——这正是人眼验不出来、KAT 一秒钟抓出来的实证红线能隔离改的是 SM3 的 IVSM4/SM2 的 PASS 不受牵连——如果有一天自检全红那是更严重的问题可能构建链被污染单条红则精确指向那一个原语为什么驱动不随仓库分发也拦不住我们标准向量是公开知识任何拿到vllm_crypto.c的人都能自己把红线立起来复验——源码开放 标准公开 可审计这正是本仓库 AGPL 双许可叙事下可验证的技术底座。4. 学员调试任务A 档板端/本地动手复刻本文搭crypto_kat.c编译运行确认 6 行 PASS依次单独篡改a)SM3_IV[0]b) 压缩常量0x79cc4519c)P0的旋转位数——每次重编跑 KAT记录哪几行 FAIL、SM4/SM2 是否受影响体会红线的隔离粒度给 harness 加一个你自己的向量SM3(中国)的期望值先用另一个可信实现算好python 有hashlib.new(sm3)的话再让引擎实现跑体会先有答案再实现。B 档纯读源码读vllm_crypto.c1–127 行回答GET_U32_BE/PUT_U32_BE宏22–28 行在做什么为什么 SM3 要大端取字vc_sm3_update的整块直压 余块缓冲两条路径90–103 行分别处理什么情况若把vc_sm3_final里while (buflen ! 56)的填充循环改成先算要补几个 0 再一次性 update行为等价吗为什么这样写更防御提示长度计数c-n的进位预期输出你自己的 KAT 输出全绿 至少一次篡改→单原语 FAIL的实验记录。收尾本篇源码点名vllm_crypto.c红线注释 4–5、IV 33–36、vllm_crypto.h、权重保护与可验证推理方案.md开源仓库Kestrel-LLM (Gitee)AGPL-3.0-or-later 或商业许可二选一下篇预告红线证明实现是对的那 SM3 内部到底怎么把abc搅成 32 字节摘要的23-2 逐段导读填充、消息扩展 W/W、64 轮压缩。 第 23-1 篇：国密 SM3 与 KAT 红线——先有答案，再写实现
1. 知识点为什么密码学需要KAT 红线普通工程代码可以看起来对 边界测试过就发布。密码学不行错一位就是整体失效哈希/加解密是雪崩式的一个常量抄错输出跟标准毫无相似度但看起来很随机——靠人眼根本验不出来标准答案免费可得GM/T 0004SM3等标准附录给了官方向量如SM3(abc) 66c7f0f4…。把这些向量写进自检等于给实现装了出厂校准——先有答案再写实现红线要能隔离理想的自检是哪个原语错就哪个红而不是一团 FAIL 让你猜——所以 KAT 要按原语分组跑。引擎的源码注释vllm_crypto.c4–5 行把这条纪律写得很直白位级正确性由独立测试驱动用国密标准 KAT 向量逐字节验证red line。文档进一步说明该驱动vllm_crypto_test.c未随仓库分发权重保护与可验证推理方案 224 行——本日我们自己搭最小 harness把这条红线在板上立起来。2. 对应代码最小 KAT harnesscrypto_kat.c对着vllm_crypto.h的公开 API写一个零依赖 harness验证四件事vc_sm3(abc, 3, d) → 与 66c7f0f4… 对拍SM3 官方向量 vc_sm3(, 0, d) → 与 1ab21d83… 对拍空串向量 vc_sm3 分块输入361 字节喂 update→ 与 abcd*16 的 64B 向量对拍走填充缓冲路径 vc_sm4_setkey_enc crypt_block → 与标准单块向量 681edf34… 对拍 vc_sm2_sign/verify → 功能回环 篡改 r 后必须验不过编译方式板端与引擎同一份vllm_crypto.cgcc -O2 -Irepo/include -Irepo/include/common \ crypto_kat.c repo/src/common/vllm_crypto.c -o crypto_kat -lm3. 改动后果板端 KAT 实测——红线为什么是红线实测口径RK3588 / aarch64 / 2026-09-07 / gcc -O2。原始实现 [PASS] SM3(abc) 66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0 [PASS] SM3() 1ab21d8355cfa17f8e61194831e81a8f22bec8c728fefb747ed035eb5082aa2b [PASS] SM3(64B abcd*16, 361) debe9ff92275b8a138604889c18e5a4d6fdb70e5387e5765293dcba39c0c5732 [PASS] SM4-ECB KAT (block) [PASS] SM2 sign/verify roundtrip [PASS] SM2 tamper rejected (r ! r) KAT: ALL PASS (red line green) 篡改后把 SM3_IV[0] 的 0x7380166f 改成 0x7380166e其余不动 [FAIL] SM3(abc) 7a3773dc0de682e8…与标准无一位相同 [FAIL] SM3() 1d6d2431… [FAIL] SM3(64B, 361) 8dfe48ba… [PASS] SM4-ECB KAT (block) ← 不受影响 [PASS] SM2 sign/verify roundtrip ← 不受影响 KAT: FAILURES PRESENT三个教训一个十六进制位 输出全变0x7380166f → 0x7380166e只是 IV 最低位 -1三个 SM3 输出立刻与标准毫无相似度——这正是人眼验不出来、KAT 一秒钟抓出来的实证红线能隔离改的是 SM3 的 IVSM4/SM2 的 PASS 不受牵连——如果有一天自检全红那是更严重的问题可能构建链被污染单条红则精确指向那一个原语为什么驱动不随仓库分发也拦不住我们标准向量是公开知识任何拿到vllm_crypto.c的人都能自己把红线立起来复验——源码开放 标准公开 可审计这正是本仓库 AGPL 双许可叙事下可验证的技术底座。4. 学员调试任务A 档板端/本地动手复刻本文搭crypto_kat.c编译运行确认 6 行 PASS依次单独篡改a)SM3_IV[0]b) 压缩常量0x79cc4519c)P0的旋转位数——每次重编跑 KAT记录哪几行 FAIL、SM4/SM2 是否受影响体会红线的隔离粒度给 harness 加一个你自己的向量SM3(中国)的期望值先用另一个可信实现算好python 有hashlib.new(sm3)的话再让引擎实现跑体会先有答案再实现。B 档纯读源码读vllm_crypto.c1–127 行回答GET_U32_BE/PUT_U32_BE宏22–28 行在做什么为什么 SM3 要大端取字vc_sm3_update的整块直压 余块缓冲两条路径90–103 行分别处理什么情况若把vc_sm3_final里while (buflen ! 56)的填充循环改成先算要补几个 0 再一次性 update行为等价吗为什么这样写更防御提示长度计数c-n的进位预期输出你自己的 KAT 输出全绿 至少一次篡改→单原语 FAIL的实验记录。收尾本篇源码点名vllm_crypto.c红线注释 4–5、IV 33–36、vllm_crypto.h、权重保护与可验证推理方案.md开源仓库Kestrel-LLM (Gitee)AGPL-3.0-or-later 或商业许可二选一下篇预告红线证明实现是对的那 SM3 内部到底怎么把abc搅成 32 字节摘要的23-2 逐段导读填充、消息扩展 W/W、64 轮压缩。