HMAC原文能直接拼接字段吗？

HMAC只处理最终消息字节，不知道这些字节原本来自几个字段。若直接拼接而不保留边界，两组不同的业务字段可能组成同一原文，得到相同认证结果。设计签名格式时，应先确定能够无歧义读取的序列化规则，再谈算法、密钥与输出表示。

2026年11月7日，www.kkce.com 操作截图。主图为2:ab1:c；补图分别记录直接相连的abc和另一长度前缀样例。不同字段划分可先得到同一abc；相同消息的认证码不能区分原来的分界。与主图仅消息不同；本轮两个长度前缀样例的输出不同。

相同原文并不是算法发生碰撞

字段ab与c直接相连为abc，字段a与bc相连也为abc。本次用KKCE HMAC计算页和公开教学密钥计算abc，再分别计算2:ab1:c与1:a2:bc，两种长度前缀样例实际得到不同结果。三图保留输入及输出，后两者的算法和密钥相同。

边界缺失发生在认证之前

前两组字段若已经被压成同一消息，认证码无法重新恢复它们的分界。这是原文构造不明确，不是HMAC失去密码学能力。检查时应先比较参加运算的实际字节，不能只看接口表格里两组字段名称或值是否不同。

序列化规则必须完整约定

长度前缀需要说明长度按字节还是字符计算、采用何种字符编码、字段顺序及空值处理。本轮样例全部为ASCII，长度容易核对。若使用分隔符，则还要定义值中出现分隔符时怎样转义，不能只加一个竖线就认定所有输入都无歧义。

把构造规则纳入双方联调样例

准备空字段、非ASCII文字及包含分隔符的值，核对序列化结果后再核对认证码。快快测帮助观察公开消息变化，生产密钥应留在相应受控流程。本文没有对真实接口发送请求，教学密钥也不用于任何业务。