Go crypto/ed25519 怎么验证带上下文的签名数据

Go 里“带上下文”的 Ed25519 验签，关键不是把上下文字符串随手拼到消息前面，而是让签名端和验签端同时使用同一份消息字节、同一个 Options.Context 和对应的公钥。签名时调用 PrivateKey.Sign，验签时调用 ed25519.VerifyWithOptions；返回 nil 才表示通过。只要原文拼接、Context 或公钥有一处不同，结果就会失败。

先把消息、Context 和公钥分成三条输入边界

ed25519.Options 有两个关键字段：Hash 为零值时是普通 Ed25519，Context 非空时选择 Ed25519ctx。Context 最多 255 字节，它参与签名域的区分，但不会替你修改 message。因此协议里既有“订单数据”，又有“订单签名上下文”时，应分别保存。

先固定签名前的规范化消息

最容易被忽略的是“看起来相同”的数据不一定拥有相同字节。例如 JSON 字段顺序、数字格式、租户前缀的分隔符不同，都会让验签失败。建议把规范化封装成一个函数，调用方只传业务字段；不要在签名端和验签端各写一份近似的拼接逻辑。

func canonicalPayload(tenant string, body []byte) []byte {
	// 用固定的 NUL 分隔租户与正文，避免边界产生歧义。
	out := append([]byte(tenant), 0)
	return append(out, body...)
}

如果协议并不要求租户进入签名原文，就不要为了“看起来有上下文”把 Context 拼进 message。此时上下文只放在 Options.Context，业务正文仍按既定协议编码。

用同一上下文完成签名与 VerifyWithOptions 验证

下面的完整片段使用一份 message 和同一个 Options。PrivateKey.Sign 的 rand 参数可以传 nil；对于 Ed25519，它不会改变这次签名的上下文选择。

package main

import (
	"crypto/ed25519"
	"fmt"
)

func main() {
	// GenerateKey(nil) 使用安全随机源生成一对密钥。
	pub, priv, err := ed25519.GenerateKey(nil)
	if err != nil {
		panic(err)
	}

	body := []byte(`{"order_id":"A-1024","amount":199}`)
	message := canonicalPayload("tenant-a", body)
	opts := &ed25519.Options{Context: "order-sign-v1"}

	// 签名端与验签端必须共享同一 Context 和 message 字节。
	sig, err := priv.Sign(nil, message, opts)
	if err != nil {
		panic(err)
	}
	if err := ed25519.VerifyWithOptions(pub, message, sig, opts); err != nil {
		panic(fmt.Errorf("签名无效: %w", err))
	}
	fmt.Println("signature verified")
}

func canonicalPayload(tenant string, body []byte) []byte {
	// 固定分隔符，确保两端不会把字段拼成另一种字节序列。
	out := append([]byte(tenant), 0)
	return append(out, body...)
}

生产代码不要只记录“验签失败”四个字。可以把 Context 名称、协议版本和消息摘要放进受控日志，但不要记录私钥或完整敏感正文。Context 改名相当于切换了签名域，旧签名不会自动兼容。

签名失败时按三类输入逐项复核

遇到 VerifyWithOptions 返回错误，先不要改算法。按下面顺序对照发送方和接收方的实际输入：

1. 比较 message：确认 JSON 编码、字段顺序、大小写、分隔符和字符集一致；最好由同一个 canonicalPayload 实现生成。
2. 比较 Context：确认没有一端传空字符串、误加空格或使用另一版协议名；Context 按字节计数，不能超过 255 字节。
3. 比较密钥：确认签名私钥对应的 PublicKey 没有被环境、租户或缓存键替换，Signature 也没有被 Base64 解码成错误的字节。

还有一个常见混淆：普通 ed25519.Verify 没有 Context 参数，不能拿它验证 Ed25519ctx 签名；需要使用 VerifyWithOptions。如果把 Options.Hash 设为 crypto.SHA512，语义会切换到 Ed25519ph，输入也应符合预哈希约定，不要和本文的默认 Ed25519ctx 写法混用。

相关问题

Context 要不要拼到 message 前面？

不必为了 Ed25519ctx 再拼一次。Context 作为 Options.Context 传给签名和验签接口；只有业务协议明确要求该字段属于原文时，才把它纳入规范化消息。

能不能用 ed25519.Verify 验证带 Context 的签名？

不能。普通 Verify 只对应没有 Context 的普通 Ed25519，带上下文时应让两端都调用 VerifyWithOptions。

为什么 message 打印出来一样仍然验签失败？

打印文本只能说明可见内容接近，不能证明字节相同。优先比较规范化后的十六进制摘要，再核对 Context、Base64 解码结果和 PublicKey 来源。

Context 可以为空吗？

可以，但空 Context 表示不选择 Ed25519ctx。若协议需要用途隔离，应固定一个非空且版本化的 Context，并在两端复用。