Go crypto/ed25519怎样签名并验证短消息为什么结果为空或不符合预期

Go 中签名短消息可直接调用 ed25519.Sign，验证用 ed25519.Verify。它们操作的是原始消息字节，不是 Base64 文本或预先做过摘要的字符串。出现空结果或验证失败时，应先检查外层错误、公私钥格式、签名解码以及两端消息字节是否一致；不要通过“修整”消息或忽略错误来让验证通过。

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

1. 接口目标：把签名结果与业务消息绑定

本例为一条库存报告状态消息生成签名，再验证原消息与变更后的消息。签名用于判断消息与对应公钥之间的关系，不会隐藏正文，也不能单独防止重放。公钥必须通过可信配置或明确的身份绑定渠道获得，不能从同一个未认证请求随意取一个公钥就据此认定发送方身份。

标准库 Sign 返回原始签名字节，没有 error 返回值；传入私钥长度不符会 panic。因此“签名字符串为空”通常来自业务包装函数返回错误、转换步骤失败或变量使用错误，并非正常签名会随机生成空值。下面包装器先检查长度，并给文本输出定义固定编码。

2. 调用方需求：区分原始字节与传输文本

调用方需要三项明确约定：消息究竟是什么字节、公钥属于谁、签名如何编码。本例消息直接用 UTF-8 字符串转成 []byte，签名文本采用 RawStdEncoding，也就是标准 Base64 字母表且不带填充。它不是 URL 安全 Base64；放入 URL 查询参数时应使用查询参数编码，或由协议双方另行约定 RawURLEncoding，不能仅一端替换。

对 JSON 消息，不能假设解析后重新序列化的字节与发送方原文一致。空白、字段顺序、数字表示和 Unicode 表示都可能变化。接口应约定对传输原文字节签名，或采用双方确定的规范化协议，再把相同字节传给签名和验证函数。

3. 参数设计：32字节种子不是64字节私钥

直接把32字节种子转换成 ed25519.PrivateKey，不会自动扩展成正确私钥。应在确认输入确实是原始种子后，使用 NewKeyFromSeed。PEM、PKCS#8、十六进制和 Base64 都是不同表示，不能把容器文本强制转换成字节切片就当作原始密钥。

长度检查只是避免错误调用，不证明任意64字节数据都是合理生成的密钥。示例通过 GenerateKey 生成匹配的一对；生产密钥加载应使用其格式对应的解析与管理流程，不要自己拼接私钥。私钥与种子不应进入文章示例输出、请求日志或错误消息。

4. 错误处理：让格式错误和不匹配各有返回

package main

import (
 "crypto/ed25519"
 "encoding/base64"
 "errors"
 "fmt"
)

// 约定输入是原始消息字节；输出采用无填充的标准 Base64。
func SignText(priv ed25519.PrivateKey, message []byte) (string, error) {
 if len(priv) != ed25519.PrivateKeySize {
  return "", errors.New("私钥字节数不正确")
 }
 signature := ed25519.Sign(priv, message)
 return base64.RawStdEncoding.EncodeToString(signature), nil
}

func VerifyText(pub ed25519.PublicKey, message []byte, text string) error {
 if len(pub) != ed25519.PublicKeySize {
  return errors.New("公钥字节数不正确")
 }
 signature, err := base64.RawStdEncoding.DecodeString(text)
 if err != nil { return fmt.Errorf("签名Base64无效: %w", err) }
 if len(signature) != ed25519.SignatureSize {
  return errors.New("签名字节数不正确")
 }
 if !ed25519.Verify(pub, message, signature) {
  return errors.New("签名不匹配")
 }
 return nil
}

func main() {
 // nil 使用标准库安全随机源；演示密钥只存在于本次进程中。
 pub, priv, err := ed25519.GenerateKey(nil)
 if err != nil { panic(err) }
 message := []byte("inventory-report:v1:ready")
 text, err := SignText(priv, message)
 if err != nil { panic(err) }
 if err := VerifyText(pub, message, text); err != nil { panic(err) }
 fmt.Println("原消息验证通过")
 // 字节不同会验证失败，不输出私钥或种子。
 changed := []byte("inventory-report:v1:changed")
 fmt.Println("变更消息验证失败:", VerifyText(pub, changed, text) != nil)
}

保存为 main.go 后可以尝试运行。预期原消息验证成功，变更消息的验证返回错误；本文没有实际运行并展示虚构输出，也不打印真实密钥。示例中的密钥每次启动重新生成，适合单进程演示，不适合跨进程保留身份。生产中应由密钥管理方式提供稳定且受保护的签名身份。

VerifyText 区分公钥长度错误、Base64 解码失败、签名长度错误和验证不匹配，便于内部定位。对外 API 可以按业务规则统一返回拒绝，避免暴露不必要的诊断细节。不要在解码错误时继续使用返回的部分数据，也不要用空切片替代失败值继续验证。

5. 兼容策略：不要混用普通Ed25519与变体

本例使用普通 Ed25519，直接签原始消息。如果一端先 SHA-512 再调用普通 Sign，另一端却验证原文，就不是相同输入。Ed25519ph 与 Ed25519ctx 有各自的选项协议，不能把“先哈希再普通签名”当作 ph 的等价替换。

确实需要变体时，应使用 PrivateKey.Sign 与 VerifyWithOptions，并明确 Hash 和 Context；相关接口自 Go 1.20 提供。上下文字符串也必须双方一致。迁移时把算法标识、编码方式、消息构造与公钥标识一起写进接口契约，不要仅修改一个函数名就期待旧客户端自动兼容。

短消息场景通常先保持普通 Sign/Verify，减少调用选项。如果消息来源是文件或网络流，还需要定义完整读取与长度限制；签名操作成功不意味着之前的读取过程没有截断。空消息本身也可以被签名，是否允许为空由业务规则决定，不能把空消息和空签名混为一谈。

6. 示例接入后的常见问题

为什么文本看起来一样却验证失败？检查两端的原始字节长度、换行和字符编码，不要自动 TrimSpace 后再试。为什么 Base64 长度不是64？64是原始签名字节数，文本编码会改变字符长度。签名成功是否保证请求没有过期？不保证；有效期、用途和唯一请求标识需要纳入明确的消息协议，并由服务端实施有效期与重放处理。

接口取舍的重点是明确参数与失败语义：签名函数只接受正确来源的私钥和约定消息，验证函数只接受可信身份对应的公钥，传输层统一编码。算法和变体规则以 crypto/ed25519 官方文档为依据，签名不代替密钥信任、授权或传输保密。