文章总结： GB/T15852.2-2024规定MAC值不小于32位，基于四重考量：安全上使瞎猜概率降至十亿分之一；工程上对齐字长与字节边界；延续3G至5G的32位MAC电信惯例；并兼容祖冲之128-EIA3输出。建议将32位仅作合规底线，高价值数据应选96位以上MAC。 综合评分： 93 文章分类： 技术标准,数据安全,应用安全,网络安全

消息鉴别码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

一个数字的四重身份

| 支柱 | 内容 | 出处 | | — | — | — | | 安全底线 | 瞎猜伪造概率2^-32；密钥穷搜索需k/m对唯一定位密钥，k=128、m=32时为4对 | GB/T 15852.2-2024附录A | | 工程粒度 | 一个32比特字、4字节，协议字段与寄存器的自然单位 | GB/T 15852.2-2024第4章（w = 32） | | 电信惯例 | f9与EIA1/2/3（及5G NIA系列）的MAC-I均为32位，自2000年前后延续至今 | ETSI TS 35 201、TS 35 221 | | 体系兼容 | 恰好容纳128-EIA3的32比特输出；GB/T 15852.3-2019即以ZUC为底层算法之一 | GB/T 33133.3-2021表2、GB/T 15852.3-2019 |

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

07

本文依据的标准与文献

| 文献 | 说明 | | — | — | | GB/T 15852.2-2024 | 网络安全技术 消息鉴别码 第2部分：采用专门设计的杂凑函数的机制（条文、附录A与附录C所本） | | GB/T 33133.3-2021 | 信息安全技术 祖冲之序列密码算法 第3部分：完整性算法（128-EIA3），表2规定MAC为32比特 | | GM/T 0001.3-2012 | 祖冲之序列密码算法 第3部分：基于祖冲之算法的完整性算法（已作废，由GB/T 33133.3-2021代替） | | GB/T 15852.1-2020、GB/T 15852.3-2019 | 消息鉴别码家族另两部分：分组密码机制／泛杂凑函数机制（后者规范性引用ZUC算法标准并给出ZUC底层测试向量） | | ISO/IEC 9797-2第三版草案（PRF，2021） | 含与国标相同的32位条款，新增SM3为专用杂凑函数17；第二版（2011年）已在ISO平台标注注销 | | ETSI TS 135 201、ETSI TS 135 221、GSMA 128-EEA3/EIA3规范、3GPP算法评估报告S3-000282 | UMTS f9与LTE 128-EIA3规范及评估，MAC均为32位 | | 3GPP Explorer：EIA词条、X-MAC词条 | LTE/5G完整性算法族与MAC-I校验机制概述 |

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

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

点赞

在看

转发

如有疑问，请联系：Mannix6

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：利刃信安 利刃信安 利刃信安《消息鉴别码MAC值的长度为什么规定应不小于32位》