摘要

  • RFC 9861 定义四种可扩展输出函数；要复现一个结果，还必须知道精确输入字节、域分离字节或定制串，以及请求的输出长度。
  • KT128 与 KT256 是否进入树形计算，取决于编码后的完整输入是否超过 8192 字节，而不只是业务消息大小。
  • IRTF Informational RFC 与 IANA 登记负责统一含义，不证明某个实现合格，也不授权任何生产用途。

迁移团队拿到了旧系统的文件、哈希值和一个算法标签：KT256。他们仍然无法重新算出同一个结果。

原因可能不是算法坏了，而是记录少了一个决定。旧系统也许用了非空定制串，也许请求了 64 字节而新系统只取 32 字节，也许两端对输入对象采用了不同序列化，或者流式接口以不同顺序拼接了分片。标签在符号层完全一致，真正进入函数的问题却不一致。

RFC 9861把这种差异写得很清楚。它在 2025 年 10 月定义 TurboSHAKE128、TurboSHAKE256、KT128 与 KT256。其发布记录表明：这是 IRTF 的 Informational 文档，代表 CFRG 共识，但不是 IETF 互联网标准；IRTF 研究成果也未必适合直接部署。公共定义与本地采用权，必须分开。

输出长度不是显示选项

TurboSHAKE 接收消息 M、域分离字节 D 和正整数输出长度 L。D 的有效范围是 01 到 7F，默认值为 1F。当 M 与 D 不变时，短输出会成为长输出的前缀。

“前缀相同”并不等于应用可以随意截断或扩长。数据库字段、协议标识、认证标签各自需要固定的比较规则。32 字节值与 64 字节值回答的是两个相关但不同的问题。若收据没有 L，以后看到十六进制字符串的长度，也无法确认那是明确的协议选择、存储截断，还是一次偶然实现限制。

流式输入也不能只记“所有块都处理过”。RFC 要求分块输入的结果等于按提交顺序把各块精确连接后一次计算；分段读取输出，也必须等于请求总长度后再按顺序切开。缓冲边界可以是实现细节，字节顺序不是。

定制串参与了密码学事实

KT128 与 KT256 使用可选定制串 C。它们先构造 S = M || C || length_encode(|C|)，把定制串及其长度可逆地纳入输入。因此，放在 C 里的协议名、URI、租户标识或用途标签，并不是哈希外围的注释。

谁负责选择 C，谁就对结果拥有实际影响力。一次 URI 规范化、字符编码变化、大小写处理或“清理元数据”的迁移，都可能在底层函数完全不变的情况下更换全部输出。若管理界面只显示 KT128，就把这项控制权藏了起来。

空串也需要说明来源。它可能是配置明确选择，也可能是某个不支持定制参数的 API 强制采用默认值，还可能是迁移中丢失了原始字段。三者今天可以产生同一输出，却对应不同的可维护性。

8192 字节边界属于一致性测试

KangarooTwelve 按 8192 字节切分 S。S 不超过该长度时走单节点路径；超过后，后续块先生成链接值，再与首块和树结构编码汇入最终节点。KT128 的链接值为 32 字节，KT256 为 64 字节。

关键在于阈值作用于 S，而 S 已经包含 C 和长度编码。即使业务消息 M 完全不变，增大定制串也能让实现从单节点跨入树模式。合格的测试应覆盖阈值前一处、阈值本身和阈值后一处，并分别使用空与非空 C。

实现可以选择串行、SIMD 或其他并行路径，但最终字节不得改变。本文没有测试任何处理器、库或吞吐量。能成立的结论只是：同一完整输入合同必须产生相同结果，性能声明不能代替这份字节证据。

固定配置名与通用函数名不是同一粒度

IANA Named Information 登记表中的 k12-256 明确表示 KT128、空 C、32 字节输出；k12-512 则表示 KT256、空 C、64 字节输出。这类名称关闭了部分参数空间，比单独写 KT128 更完整。

IANA COSE Algorithms 登记表还为四种函数分配了编号。编号使协议能够引用同一公共定义，却不能证明本机库支持所有参数、通过了测试向量、保护了密钥，或为业务选对了长度。

RFC 对 128 系列主张 128 位安全强度，对 256 系列主张 256 位，其依据是对 12 轮 Keccak 的密码分析和树模式的 Sakura 编码论证。NIST FIPS 202给出 Keccak/SHA-3 基础，NIST SP 800-185提供相邻派生函数背景。这是设计依据，不是对某个二进制、硬件后端或侧信道防护的认证。

一个“已报告”勘误说明标签为什么重要

RFC 9861 给出大量测试向量，覆盖不同函数、输出长度、消息规模、定制规模与树边界。当前 RFC 勘误页面列出技术勘误 8997，状态仍为 Reported。它指出若干 KT 测试调用的第一个位置参数省略了显式 M= 标签；建议修订统一参数写法，并没有更换列出的输出字节。

Reported 不是 Verified，提议修订也没有自动写回不可变的 RFC 正文。验证记录应保留准确状态，并为每个向量保存完整参数、期望输出、实际输出、库版本、硬件路径与时间。只保存“测试通过”无法支持下一次复现。

字节相等仍不是业务结果

RFC 还定义 HopMAC，并允许用可逆方式把密钥放在输入前后，包括对短消息把密钥作为 KT 定制串。因此，“KT128 MAC”仍不够完整：还要知道具体构造、密钥标识与保管边界、C、标签长度和侧信道假设。

即便所有字节相等，也只能证明某组明确输入得到了某组预期输出。它不证明消息作者、内容新鲜度、操作授权或下游成功。正确的证据链应把公共定义、参数配置、字节序列化、运行执行、结果比较、协议接受与现实效果分别记录，再通过引用连接起来。

来源