首页 > Golang > Go问答

Go hmac.Equal 能否直接比较不同长度摘要

来源：17golang原创

时间：2026-11-14 15:52:44 434浏览收藏

可以直接传入，长度不同不会 panic，但结果一定是 false。hmac.Equal 接受两个 []byte，先由长度边界决定是否还有必要做逐字节比较；只有长度相同，才进入常数时间的字节比较。

我在排查回调签名时遇到过一个容易误判的现象：一边是 SHA-256 的 32 字节摘要，另一边因为解码失败只剩下几字节，调用 hmac.Equal 只是返回不匹配，并不会替你指出“算法不同”还是“输入被截断”。所以，答案分成两层：API 可以直接比较不同长度；业务上仍应先保证两边代表同一种 MAC。

不同长度时，hmac.Equal 会返回什么

Go 官方 crypto/hmac 的公开函数签名是 Equal(mac1, mac2 []byte) bool。它不要求调用方先手动判断长度，也不会因为两个切片长度不同而抛出异常。长度不同的调用结果就是 false。

这个行为和“常数时间比较”并不矛盾。Go 源码明确把长度不同看成不需要继续逐字节比较的情况：长度已经足够证明两个 MAC 不相等；长度相同时，才调用 crypto/subtle 的常数时间比较。换句话说，常数时间保护的是相同长度 MAC 的内容比较，不是让所有输入都经过完全一样的工作量。

Go hmac.Equal 比较两个 MAC 时的输入、长度边界和常数时间比较关系图 — 图1：hmac.Equal 的长度边界与比较接口说明图，不是截图或运行证据。

为什么“能比较”不等于“应该混着比较”

如果一边是 SHA-256 HMAC，另一边是 SHA-512 HMAC，它们本来就不是同一种 MAC。此时长度不同通常会很快得到 false；即使两个算法恰好产生相同长度，也不能因此认为它们可以互换。

同样要注意编码层。HTTP 头里常见的是 Base64 或十六进制文本，hmac.Equal 比较的应该是解码后的原始 MAC 字节，而不是一边传编码文本、一边传原始字节。编码文本长度变化、尾随换行、URL 安全字母表不一致，都可能让“摘要长度问题”看起来像 HMAC 失效。

我会把校验前提固定成三个条件：消息相同、密钥相同、哈希实现和表示方式相同。满足这些条件后，收到的 MAC 长度异常就让它自然返回 false；不要为了凑长度而截断、补零或重新编码。

工程代码应该先保证两边是同一种 MAC

下面的写法把“重新计算”和“比较”分开。服务端根据同一条消息和共享密钥重新生成期望值，再把请求中的签名解码成字节，最后交给 hmac.Equal。示例只展示比较边界，不包含具体 Web 框架或回调协议。

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/base64"
    "fmt"
)

// validMAC 只比较同一算法生成的原始 MAC 字节。
func validMAC(message, receivedText, secret []byte) bool {
    mac := hmac.New(sha256.New, secret)
    // 写入与发送方约定的原始消息，错误时直接拒绝当前请求。
    if _, err := mac.Write(message); err != nil {
        return false
    }
    expected := mac.Sum(nil)

    // 先解码传输层文本；截断或非法 Base64 会在这里失败。
    received, err := base64.StdEncoding.DecodeString(string(receivedText))
    if err != nil {
        return false
    }

    // 长度不同会得到 false；长度相同时由 hmac.Equal 做安全比较。
    return hmac.Equal(received, expected)
}

func main() {
    fmt.Println(validMAC([]byte("order-42"), []byte("invalid"), []byte("shared-secret")))
}

这里没有手动写 if len(received) != len(expected)，因为 hmac.Equal 已经覆盖了这个边界。手动判断长度可以用于更早返回或记录指标，但不要把它替换成 bytes.Equal 来比较认证标签。