Go crypto/ed25519怎样签名并验证短消息怎样完成一个可复用的最小示例

想用 Go 给一段短消息做签名，最小闭环就是：用私钥调用 ed25519.Sign 生成签名，再把公钥、同一份消息字节和签名交给 ed25519.Verify。验证返回 true 只表示这份签名与这份消息和公钥匹配；它不自动完成身份认证、授权、密钥托管或防重放。

官方文档：https://pkg.go.dev/crypto/ed25519

1. 问题原文：怎样给短消息签名并验证？

可以把问题拆成四个对象：消息是需要保护的字节，私钥只在签名端使用，公钥交给验证端，签名是由私钥和消息共同得到的结果。验证端必须拿到原始消息字节；哪怕只是编码、空格或换行发生变化，验证结果也可能变成 false。

这个场景适合用标准库的 Ed25519 接口做一个小而清楚的闭环。文章只围绕“签名短消息并验证”展开，不把它扩展成证书体系或完整登录协议。

2. 先给结论：签名和验证依赖同一份消息字节

生成密钥时可以调用 ed25519.GenerateKey(nil)，把随机源交给标准库处理。签名时只传入私钥和消息，返回的签名长度是64字节。验证时传入公钥、原消息和签名，返回布尔值。

实际项目不要把每次启动生成的私钥当成长期身份。示例为了可读性现场生成密钥；生产代码应按密钥生命周期保存私钥，并通过明确的编码约定构造消息，例如先确定字段顺序、字符集和换行规则，再交给签名函数。

3. 正确做法：用一个最小示例完成Sign和Verify

下面的示例故意保留两个验证对象：原始消息应该通过，被复制后修改一个字节的消息应该失败。代码没有连接网络，也没有把预期结果冒充成已执行输出。

package main

import (
	"crypto/ed25519"
	"fmt"
)

func main() {
	// nil表示使用标准库提供的安全随机源生成一对密钥。
	publicKey, privateKey, err := ed25519.GenerateKey(nil)
	if err != nil {
		panic(fmt.Errorf("生成Ed25519密钥失败: %w", err))
	}

	message := []byte("订单状态:已支付")
	// Sign只接收私钥和消息，返回固定长度的签名字节。
	signature := ed25519.Sign(privateKey, message)

	// 验证时必须传入签名时的同一份消息字节。
	originalOK := ed25519.Verify(publicKey, message, signature)

	changedMessage := append([]byte(nil), message...)
	// 复制后只改动一个字节，用来说明签名绑定的是消息内容。
	changedMessage[len(changedMessage)-1] ^= 1
	changedOK := ed25519.Verify(publicKey, changedMessage, signature)

	fmt.Printf("原消息验证=%t，改动后验证=%t，签名长度=%d\n",
		originalOK, changedOK, len(signature))
}

这里的 append([]byte(nil), message...) 是为了复制消息，避免修改原切片。签名结果是字节切片，传输到 JSON、HTTP 头或文本存储时还需要约定 Base64 或十六进制编码；编码只影响外层表示，验证前必须解码回原始签名字节。

如果示例只验证原消息，最容易漏掉的排查项是“签名端和验证端是否对同一份字节签名”。建议把序列化后的最终字节作为协议输入，而不是让两端各自重新拼接字符串。

4. 常见误区：验证通过不等于业务身份已经可信

因此，Ed25519 在这里解决的是消息完整性和“持有对应私钥者才能产生匹配签名”这一密码学关系。谁有权使用公钥、消息能否重放、密钥如何轮换，都要由上层协议补齐。

5. 边界情况：长度、选项和输入处理

官方包提供了 PublicKeySize=32、PrivateKeySize=64、SignatureSize=64 和 SeedSize=32 等常量。Sign 在私钥长度不正确时会 panic，Verify 在公钥长度不正确时也会 panic；如果密钥来自外部输入，应先做长度检查并把解析失败当成普通错误处理。

普通 Ed25519 直接对原消息操作，不要为了“保险”在两端各自先做一次未约定的哈希。若确实需要使用带选项的 Ed25519ctx 或 Ed25519ph，应让签名端和验证端同时使用 PrivateKey.Sign 与 VerifyWithOptions，并明确上下文和预哈希规则。

6. 延伸问题：什么时候需要换成VerifyWithOptions？

如果协议就是普通 Ed25519，优先使用简单的 Sign 和 Verify，让消息字节边界更容易审查。只有在协议明确要求上下文区分或 Ed25519ph 预哈希时，才选择带选项的接口；这时需要把选项作为协议的一部分固定下来，不能让一端默认、另一端自定义。

私钥可以直接转成字符串保存吗？可以做编码后保存，但不能把编码当作加密；保存位置仍需访问控制和密钥轮换。

消息很长还能用这个示例吗？接口可以接收字节切片，但本文只讨论短消息闭环；大消息、流式处理和预哈希应按双方协议选择合适的变体。

验证失败时先改哪里？先固定消息序列化和编码，再确认公钥与私钥属于同一对，最后检查签名传输过程是否发生了截断或错误解码。