消息鉴别码MAC值的长度为什么规定应不小于32位

原创

利刃信安
利刃信安

利刃信安

2026年8月18日 10:30
北京

在小说阅读器读本章

去阅读

消息鉴别码MAC值的长度为什么规定应不小于32位

GB/T 15852.2-2024《网络安全技术 消息鉴别码 第2部分：采用专门设计的杂凑函数的机制》第5章对MAC长度提出两处硬性要求。第一处是对全部三种算法的总体要求：\"使用本文件中给出的MAC算法的用户需要选择……MAC的位长度m，其中m不小于32。\"

第二处是分算法的约束：

对于MAC算法1和算法2，MAC的长度m应是一个正整数并且不大于杂凑值长度LH。对于MAC算法2，MAC值的长度m应不小于32位。对于MAC算法3，MAC的长度m是一个正整数并且不大于杂凑值长度的1/2，即m ≤ LH/2。

以SM3为杂凑函数时LH = 256，HMAC（即MAC算法2）的合法取值区间是[32, 256]。一个流传的解释是：这个32是为了顾全祖冲之序列密码的完整性算法128-EIA3，因为它的MAC恰好是32比特。这个猜测方向是对的，但只说出了四分之一的故事。把ISO的修订稿、3GPP的规范和标准自身的安全性分析并排放在一起看，32这个下限同时压在四根支柱上。

01

条文是2024年修订新增的

GB/T 15852.2-2024的前言列出相对2012年版的主要技术变化，其中d项写道：\"增加了关于MAC值和输入数据串长度限制的说明（见第5章）\"。也就是说，\"不小于32位\"是本次修订才落进条文的，2012年版没有这句话。追问\"为什么是32\"，实际是在追问2024年前后修订者写了什么、以及他们当时面对着什么。

同一时期，ISO/IEC JTC 1/SC 27完成了ISO/IEC 9797-2的第三版修订，第二版（2011年）现已在ISO官方平台标注注销。可公开查阅的第三版草案（PRF，2021）第5章含同一条款：

For MAC Algorithm 2, the length m of MAC value shall be at least 32 bits.

国标与这份草案的对应远不止这一句：草案把SM3列为\"专用杂凑函数17\"并纳入各算法的可选杂凑函数范围，恰好对应国标前言里\"更改了可选的杂凑函数的范围\"和\"增加了采用SM3密码杂凑算法的MAC算法1和MAC算法3的描述\"；连\"算法3是输入不超过256位的MDx-MAC变种\"这一结构也一一对应。两者本就同源：GB/T 15852.2-2024附录B的对象标识符自始挂在 iso(1) standard(0) message-authentication-code(9797) part(2) 弧下。所以条文的直接源头是与ISO/IEC 9797-2第三版修订的技术对齐。真正需要解释的是：无论在中国还是在ISO，为什么偏偏选中32。

02

32是安全模型的底线

GB/T 15852.2-2024附录A（资料性）逐一分析了四类攻击。对任何MAC算法，最朴素的是瞎猜：

猜测MAC：这种伪造是不可验证的，成功概率为max(1/2^m, 1/2^k)。

只要密钥长度不小于m（本文件对密钥的要求远高于此——例如算法2要求密钥长度不小于杂凑值长度256位），公式里的主导项就是2^-m。m = 32意味着单次瞎猜的得手概率约为四十三亿分之一（2.3×10^-10）；m = 16则为六万五千分之一，在百万级消息量的协议里已不可接受。这是一道\"及格线\"：标准正文同时声明\"具体的MAC算法和m值的选择超出了本文件所规定的范围\"，附录A只协助使用者评估——32不承诺安全，只保证任何声称合规的机制不会比这更糟。

附录A里另外三类攻击的代价并不由m独自决定，但m都出现在它们的数据需求里。密钥穷搜索要付出平均2^(k-1)次MAC运算的代价，且\"需要k/m对（消息，MAC）以唯一确定密钥\"；附录A自己举的例子是k = 128、m = 64——一个（消息，MAC）对过滤后仍剩约2^64个候选密钥。m越小，每一对筛除得越慢，唯一定位密钥所需的对数越多：k = 128时，m = 32需4对，m = 16需8对，m = 8需16对。真正卡住攻击者的是2^(k-1)的计算量，标准据此给出的对策是选足密钥长度，并控制同一密钥下（消息，MAC）对的暴露数量。生日攻击瞄准迭代结构的内部碰撞，数据需求约为2^(n/2)个已知消息和2^(n-m)个选择消息（n为杂凑内部状态宽度，SM3为256位）；代入m = 32即 2^128 与 2^224，均不可行，标准还提示可在消息前加序列号让MAC带状态来规避。四类攻击中，成功概率由m直接决定的只有瞎猜一项，32把它钉在十亿分之一量级以下。

值得注意的是，GB/T 15852.2-2024附录C给出的HMAC测试向量全部取128位MAC值。在起草者眼中，32是下限，不是推荐值。

03

32是一个字的宽度

GB/T 15852.2-2024第4章符号表规定：\"w：字的位长度，取32。\"SM3的字、常数与模加全在32比特字上运算。协议字段的长度也通常锚定在字节边界上，非整字节的取值并不划算：37位与40位同样占5字节，一个比特也省不下来；21位要占3字节，白白浪费3位。把下限定在4字节的32，向上64、96、128、160、192、224、256全部落在字节边界上——这是把数学约束（正整数、不超过LH）翻译成工程约束后的自然结果。顺带一提，32位也是LTE完整性保护中计数器COUNT的宽度。

04

32是电信现网二十多年的惯例

这是32最有分量的一根支柱。移动通信网络从3G时代起就把空口完整性保护的MAC定在32位：

• UMTS完整性算法f9（基于KASUMI）输出32位MAC-I，ETSI TS 135 201开篇即写明\"The integrity algorithm f9 computes a 32-bit MAC\"；
• LTE实际生效的三个完整性算法EIA1（SNOW 3G）、EIA2（AES）、EIA3（ZUC）输出的MAC-I/X-MAC-I全部是32位（另有不施加保护的EIA0）；
• 5G（TS 33.501）的NIA系列沿用同一套MAC-I/X-MAC-I校验框架，仍为32位。

电信选择32位不是拍脑袋。LTE的RRC与NAS信令都携带4字节MAC-I字段，标签每多一字节，数以亿计的终端与基站每天就多付出可观的带宽和功耗；而每消息2^-32的伪造概率，配合COUNT单调递增与重放防护，在2000年前后的3GPP算法评估中获得通过。这个权衡比祖冲之算法的标准化早了十余年。

05

祖冲之128-EIA3恰好站在交点上

GB/T 33133.3-2021《信息安全技术 祖冲之序列密码算法 第3部分：完整性算法》表2规定输出参数只有一项：MAC，比特长度32。它的前身GM/T 0001.3-2012表2同样规定MAC为32比特，且前言明确\"本部分内容同3GPP LTE机密性和完整性算法标准128-EIA3规范（ETSI/SAGE TS 35.221）保持一致性\"。

算法结构解释了为什么恰好是32：128-EIA3把ZUC密钥流组织成32比特的字，消息比特逐位挑选密钥流字做异或累加得到32比特的T，再与两个密钥流字异或输出MAC——结果天然就是一个密钥流字的宽度。GSMA的128-EIA3规范把核心部件描述为\"a universal hash and ZUC\"，即通用杂凑函数加密钥流掩码的构造，结构上属于GB/T 15852家族第3部分\"采用泛杂凑函数的机制\"一类，虽然它并不由该部分定义。

于是出现了一个体系性的对仗。GB/T 15852家族的三个部分覆盖三类机制：第1部分采用分组密码（GB/T 15852.1-2020），第2部分采用专门设计的杂凑函数（GB/T 15852.2-2024），第3部分采用泛杂凑函数（GB/T 15852.3-2019）。第3部分本身就与祖冲之血脉相连：其规范性引用文件包含GB/T 33133.1-2016（祖冲之算法第1部分），附录A列举了底层采用ZUC或SM4的MAC测试向量，附录C专门介绍ZUC与SM4的抗攻击能力。祖冲之体系与MAC标准族的交叉，早在2019年就写进了条文。假如第2部分的下限高于32，采用杂凑函数的MAC机制与体系内既有的32位MAC工程实践之间就会出现空档；设在32，128-EIA3的32比特输出不多不少正好落在边界上。从这个意义上说，\"32顾全了祖冲之\"是成立的：它是让国密MAC标准与自家电信密码算法体系严丝合缝的那块榫卯。

不过因果箭头要摆正。128-EIA3的32位继承自3GPP的MAC-I传统，那条传统比它更老；ISO/IEC 9797-2草案里的同一句话在文本上不晚于国标出现。准确的说法是：祖冲之128-EIA3是32位MAC工程传统最重要的国密承载者，国标的32位下限与它在标准体系内互相印证，而非专门为它让路。

06

一个数字的四重身份

对实现者和选型者，落点很直接：32是\"应不小于\"的合规底线，不是设计目标。带宽敏感、配合计数器防重放的场景可以从32位起步；高价值数据宜按附录A的攻击模型评估后取96位以上（SM3-HMAC的最大余量是256位）。标准划出下限，是把\"多短算太短\"的判断权连同责任一起交还给使用者——而它自己给出的那条线，站在安全、字长、电信惯例与国密体系的交汇处，恰好是32。

07

本文依据的标准与文献

我是利刃信安，网络安全和密码安全、数据安全领域的小白。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见

点赞

在看

转发

如有疑问，请联系：Mannix6