Go crypto/hmac 怎么比较签名避免时序差异

Go 服务校验接口签名时，正确做法是先用同一把密钥和同一份请求字节重算 HMAC，再调用 hmac.Equal 比较两个 MAC。不要把摘要转成字符串后使用 ==，也不要在比较前先做会提前返回的自定义循环。这样只能解决 MAC 比较阶段的时序差异，不能替代时间戳校验、重放保护和权限判断。

HMAC摘要和比较路径怎么对应

HMAC 不是对密钥和字符串简单拼接后做一次哈希，而是由密钥、哈希函数和消息共同产生 MAC。服务端验证时不需要“解密”签名，只需重新计算一份期望值。Go 官方 crypto/hmac 文档明确建议使用 Equal 比较 MAC，以避免时序侧信道。

下面的链路里，HTTP请求 提供签名原文，hmac.New 绑定哈希函数和密钥，mac.Write 接收原文字节，mac.Sum 生成期望 MAC，最后由 hmac.Equal 完成比较。比较两侧必须是同一种表示：如果请求头传的是 Base64，就先解码；如果传的是十六进制，就先用十六进制解码。

package main

import (
    "crypto/hmac"
    "crypto/sha256"
)

// CalculateMAC 使用协议约定的密钥和原文字节计算 HMAC-SHA256。
func CalculateMAC(message, key []byte) []byte {
    mac := hmac.New(sha256.New, key)
    // 写入的必须是签名协议定义的原始字节，不能临时改成格式化字符串。
    _, _ = mac.Write(message)
    return mac.Sum(nil)
}

// VerifyMAC 只负责比较已解码的 MAC，不把编码问题混进比较逻辑。
func VerifyMAC(message, key, receivedMAC []byte) bool {
    expectedMAC := CalculateMAC(message, key)
    return hmac.Equal(receivedMAC, expectedMAC)
}

hmac.Equal 的参数是两个 []byte，返回值是布尔值。它适合比较 MAC，不代表收到的内容已经可信；调用方仍要先限制请求体大小，并按接口协议确认待签名字段的顺序和分隔方式。

签名不一致时，先查哪几个边界

如果 hmac.Equal 返回 false，不要先怀疑 Go 的 HMAC 实现。最常见的原因是两端签名的字节序列不同：客户端签的是 JSON 紧凑文本，服务端却重新编码成了带空格或不同字段顺序的 JSON；或者客户端签的是完整请求体，服务端读取后又追加了换行。

第二个容易忽略的边界是比较前的解码。解码失败应该直接拒绝请求；不要为了“让长度一致”补零，也不要截断较长签名。不同长度的 MAC 也应交给 hmac.Equal 处理，业务层只记录不含密钥和完整签名的诊断信息。

把校验函数收敛成可复用入口

实际 HTTP 处理器可以让入口函数只做三件事：读取并限制请求体、解析签名头、调用验证函数。验证函数内部先解码签名，再生成期望 MAC，最后比较；时间戳和 nonce 则在 MAC 校验通过后继续做协议级检查，顺序以接口约定为准。

package signer

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

var ErrInvalidSignature = errors.New("invalid signature")

// VerifyHMAC 解码请求头中的 Base64 签名，并与原始请求体的期望 MAC 比较。
func VerifyHMAC(body, key []byte, encoded string) error {
    received, err := base64.StdEncoding.DecodeString(encoded)
    if err != nil {
        // 编码错误和签名不匹配对外统一返回，避免泄露内部细节。
        return ErrInvalidSignature
    }
    mac := hmac.New(sha256.New, key)
    // body 必须是协议规定的原始请求字节，而不是重新编码后的对象。
    _, _ = mac.Write(body)
    expected := mac.Sum(nil)
    if !hmac.Equal(received, expected) {
        return ErrInvalidSignature
    }
    return nil
}

这段封装没有把密钥、收到的完整签名写入日志，也没有把校验失败细分成“长度错、内容错、解码错”返回给客户端。生产日志可以记录请求 ID、算法版本和失败阶段，但要避免记录可直接复用的签名材料。

常见问题

普通的 bytes.Equal 能不能比较 HMAC？

从结果判断上可以比较字节是否相等，但用于认证 MAC 时优先使用 hmac.Equal，因为它就是为避免比较时序信息泄露提供的 API。

hmac.Equal 能防止重放请求吗？

不能。它只判断收到的 MAC 是否与期望 MAC 相同。请求仍应把时间戳、随机数或唯一请求 ID纳入签名，并在服务端维护时间窗口或已使用记录。

为什么双方密钥一样，签名仍然不一致？

先逐字节核对待签名原文，再核对密钥的解码方式和签名输出格式。JSON 字段顺序、换行、字符编码以及 Base64 是否带填充，都会改变最终字节。