一场 8700 万美元的损失,源头竟然是一个叫 MAC 的东西

2024 年 12 月,某头部 DeFi 协议被攻击,损失超过 8700 万美元。事后安全团队复盘报告里反复出现一个缩写——MAC。不是苹果电脑,也不是某个交易所的内部代号,而是密码学里最基础、最容易被工程团队"想当然"的一块拼图:消息认证码(Message Authentication Code,简称 MAC)。

说它基础,是因为几乎所有 TLS 握手、区块链签名、API 接口鉴权背后都有它的身影;说它容易被忽略,是因为太多开发者在选型时随手写一句 hmac = true,根本没去想底层到底跑的是 HMAC、CMAC 还是 GMAC,更没想过 nonce 重用会怎样。

在 AI 客服满天飞、安全审计动辄百万的今天,真正毁掉一个项目的,往往不是花哨的零日漏洞,而是这种"大家都懂、没人细看"的基础组件。本文不打算重复教科书定义,而是把 MAC 在 2026 年的真实使用场景、踩坑案例、横向对比一次说透。

一、MAC 到底是什么:别再把它和数字签名混为一谈

1.1 一个最容易被绕晕的区分

很多人第一次接触 MAC,会和"数字签名"搞混。两者都解决"这条消息是不是真的、没被改过",但实现路径完全不同。

  • MAC(消息认证码):基于对称密钥,通信双方共享同一把密钥,速度快,但没法解决"第三方验证"问题。
  • 数字签名:基于非对称密钥,任何人都可以用公钥验证,适合公开场景。

在区块链里,一笔交易的"授权"用 ECDSA 签名,但链下节点之间的 API 调用、跨链桥的消息传递、钱包 SDK 与服务端的鉴权,几乎全靠 MAC。据公开数据显示,2025 年公开的链上相关安全事件中,有接近 38% 与 MAC 的错误使用直接或间接相关,这个比例远高于想象。

1.2 MAC 的家族成员,你用过哪几个?

  • HMAC(基于哈希):用 SHA-256 之类哈希函数构造,工程实现最简单,生态最成熟,几乎所有 Web3 后端默认选项。
  • CMAC(基于分组密码):底层是 AES,适合硬件加密机场景,国密 SM4 对应的就是这一脉。
  • GMAC(GCM 模式里的认证部分):速度快、能并行,在高频撮合系统里很常见,但nonce 重用 = 直接 GG。
  • Poly1305:ChaCha20-Poly1305 是 TLS 1.3 标配,移动端和弱网环境表现优于 AES-GCM。

选哪个,不是看"哪个更安全",而是看你的密钥管理能力、吞吐要求、硬件兼容性。很多团队上来就上 GMAC,结果 nonce 用计数器实现,服务重启一次直接撞号,这种事故在 2025 年的交易所 API 升级里出过不止一次。

二、5 个最常见的实战陷阱:别再"想当然"用 MAC

2.1 陷阱一:把 MAC 当加密用

MAC 只保证完整性和真实性,不保证机密性。意思就是,如果消息里写了"用户 A 向用户 B 转账 1000 USDT",MAC 能保证这段话没被改,但任何截获消息的人都能直接读懂。

正确做法是Encrypt-then-MAC:先加密,再对密** MAC。这是 TLS 1.3 的标准做法,但很多自研协议为了"省事",先 MAC 再加密,结果中间人能根据明文长度反推敏感信息。Gate.io 在 2024 年公开的技术博客里就专门提过这个问题,他们早期内部 RPC 框架吃过这个亏。

2.2 陷阱二:密钥硬编码、密钥复用

2025 年 Q3,行业内部观察发现,至少有 3 起中等规模项目被攻击,根源是 HMAC 密钥直接写死在 GitHub 公开仓库里,被自动化扫描工具在数小时内发现。

更隐蔽的是密钥复用:同一个 HMAC 密钥既用来签 API 请求,又用来签 WebSocket 消息,一旦其中一处泄露,整套系统全部裸奔。火币(HTX)早期某 SDK 就因为这个问题被白帽子提交过漏洞,虽然没造成资产损失,但评级为"高危"。

2.3 陷阱三:时间戳验证形同虚设

防重放攻击的标准做法是nonce + 时间戳。但很多项目只校验了 nonce 唯一,没校验时间戳偏差,或者时间戳允许 ±1 小时偏差——这窗口大到足够攻击者反复重放。

OWASP 在 2025 年的 API 安全 Top 10 里专门点名这个问题。建议时间戳偏差控制在 ±5 分钟以内,而且必须服务端取时间,不能信客户端传的 timestamp。

2.4 陷阱四:GMAC 的 nonce 重用灾难

AES-GCM 是目前 TLS、HTTPS、区块链节点通信最常用的认证加密套件。它快、安全,但有一个"硬伤":同一个密钥下,nonce 绝对不能重复。

重复一次,攻击者就能恢复明文;重复两次,密钥直接泄露。2017 年学术论文里就给出过攻击模型,但 2024 年仍有项目因此中招——某 DEX 撮合引擎升级时,运维误把随机 nonce 改成了固定值,上线两小时就触发告警,所幸风控及时熔断。

2.5 陷阱五:在 AI Agent 时代,机器签的请求谁来认?

2026 年最值得警惕的新场景是AI Agent 自动调用链上合约和中心化 API。Agent 之间的鉴权,本质上是"机器对机器"的 MAC 问题。

但当前大量 Agent 框架默认把密钥放在环境变量里,或者直接塞进 prompt。这种做法在传统 Web 场景下已经够危险,在 Agent 场景下更甚——因为 Agent 的对话历史可能被外部数据污染,密钥有"间接泄露"的风险。

Coinbase Developer Platform 在 2025 年底发布的《Agentic API Security Guide》里建议:MAC 密钥必须绑定到 Agent 实例而非环境,并且每次调用使用派生密钥(KDF),哪怕 Agent 被注入攻击,泄露的也只是这一次会话的密钥。

三、横向对比:HMAC vs GMAC vs Poly1305,选型不再纠结

3.1 性能维度

在主流服务器 CPU 上(Intel Ice Lake 及以上),三条路的吞吐量差距其实很小:

  • AES-GCM(GMAC):单核可达 5-8 GB/s,适合高吞吐撮合、网关层。
  • ChaCha20-Poly1305:在没有 AES-NI 的 ARM 设备上表现更好,移动端首选。
  • HMAC-SHA256:软件实现成熟,吞吐量约 1-2 GB/s,但代码可控性最强。

3.2 安全维度

从纯密码学强度看,三者都达到了 128 位以上安全等级。真正的安全差距在实现细节:HMAC 最不容易踩坑,但缺乏 AEAD(认证加密)语义;GMAC 一旦 nonce 出问题就是灾难;Poly1305 没有专门硬件加速,但在 ARM 生态里被广泛验证。

3.3 工程维度

对中小团队的建议:优先选 Poly1305(ChaCha20-Poly1305 套件),原因不是它最快,而是它的实现库经过多年打磨,nonce 管理清晰,文档完善。Go、Python、Node.js 的主流加密库都默认提供,几乎不需要自己造轮子。

只有在合规要求必须使用国密(如 SM4)时,才考虑 CMAC。

四、2026 年的底层逻辑:MAC 为什么又一次被推到台前

4.1 量子计算的"渐进威胁"

虽然 Grover 算法理论上能把对称加密的安全强度"砍半",但 256 位密钥依然足够。真正受量子威胁的是非对称签名(ECDSA、EdDSA),MAC 反而是后量子时代最稳的组件之一。

NIST 在 2024 年确定的 ML-KEM、ML-DSA 等后量子标准里,依然保留了 HMAC 作为 fallback 方案。这意味着无论上层签名算法怎么换,MAC 这一层在中长期内都不需要大改。

4.2 多方计算(MPC)钱包的普及

OKX、Binance、Fireblocks 等主流托管方案,2025 年起大规模上线 MPC 钱包。MPC 的核心就是把"一把私钥"拆成多份,每份参与签名计算。在这个流程里,各参与方之间的通信鉴权靠的就是 MAC 和 AEAD。

也就是说,MAC 的正确实现,直接决定了 MPC 钱包能不能"既分权又可信"。

4.3 监管合规的硬要求

欧盟 MiCA、新加坡 MAS、中国香港的 SFC Type 7 升级,都明确要求:客户资金的 API 调用必须使用强认证机制,MAC + TLS 1.3 是底线。

这不是技术选择,而是合规底线。2026 年还想做合规市场的项目,MAC 这块基本功必须扎实。

五、行动建议:从今天开始,你可以做的 3 件事

如果你正在做链上项目、交易所撮合、或者 Agent 类应用,MAC 这一关绕不开。与其等审计报告里被点名,不如现在就开始:

  • 审计现有代码:grep 一下 HMAC、GCM、Poly1305 关键字,看密钥来源、nonce 生成、时间戳校验这三处。
  • 统一 AEAD 选型:别再混用多种 MAC,选一种(推荐 ChaCha20-Poly1305)作为团队标准,降低认知负担。
  • 把密钥管理纳入 CI/CD:硬编码、复用、过期不轮换,是 2026 年最容易踩的三类问题。

说到底,密码学不是用来"秀技术"的,而是用来"不出事"的。MAC 这个看似古老、基础的组件,在 AI Agent、MPC、跨链桥这些新场景里,反而成了最容易被忽视的承重墙。哪天你看到某个项目方公告"已通过 Certik 审计",不妨多问一句:MAC 那块,真的自己看过了吗?