Go crypto/ed25519怎样签名并验证短消息怎样在批处理代码中减少额外分配

我在批量给短消息做完整性校验时，最先踩到的坑不是 crypto/ed25519 不会用，而是把“减少额外分配”误解成了“整个签名过程必须零分配”。更准确的做法是：用 GenerateKey 得到密钥对，用 Sign 生成签名，再用同一份消息、公钥和签名调用 Verify；批处理优化则集中在循环外复用消息字节、预分配结果容器，并把 Base64 等展示编码延迟到真正需要时。

官方地址：https://pkg.go.dev/crypto/ed25519

这篇只讨论短消息的签名验证和调用方可控的分配。密钥托管、防重放、业务授权和协议设计需要单独设计，不能靠一段 Sign 调用替代。

先定边界：签名不是加密，Verify 也不返回解密结果

ed25519 是数字签名算法。发送方用私钥对消息签名，接收方拿公钥验证“这份签名是否对应这份消息”。消息内容本身不会因为调用 Sign 而被隐藏，验签成功也不会生成一份新的明文。

最小流程：短消息怎样完成签名和验证

实际接入时，我会先把密钥生成放在批处理入口之外。GenerateKey(nil) 使用安全随机源生成密钥对；短消息准备好后，私钥负责签名，公钥负责验证。验证结果是布尔值，消息哪怕只改一个字节，也应该得到 false。

package main

import (
	"crypto/ed25519"
	"fmt"
	"log"
)

func main() {
	// 把密钥生成放在批处理循环外，避免每条消息都重新生成密钥。
	publicKey, privateKey, err := ed25519.GenerateKey(nil)
	if err != nil {
		log.Fatal(err)
	}

	message := []byte("order:20261108")
	// Sign 返回一份新的签名切片；这里不把它误称为复用缓冲区。
	signature := ed25519.Sign(privateKey, message)
	valid := ed25519.Verify(publicKey, message, signature)
	fmt.Println("签名长度:", len(signature), "验证结果:", valid)

	// 改动消息后再验签，结果应为 false，因为签名绑定的是原始字节。
	message[0] = 'X'
	fmt.Println("修改消息后:", ed25519.Verify(publicKey, message, signature))
}

这里最值得记住的是参数关系：Verify(publicKey, message, signature) 中的 message 必须和签名时的字节完全一致。若上游先做 JSON 排序、空白清理或编码转换，签名和验签两端必须采用同一规则。

批处理优化：把可控分配移到循环外

当消息只有几十个字节时，真正容易被放大的往往不是算法本身，而是循环里的字符串转字节、结果切片扩容和重复 Base64 编码。我的做法是先决定批处理需要保留什么：如果下游直接接受二进制签名，就不要提前编码；如果必须写入文本协议，再在离开核心循环后编码。

package main

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

type SignedItem struct {
	Message   []byte
	Signature []byte
}

func signBatch(privateKey ed25519.PrivateKey, messages []string) []SignedItem {
	// 提前设置容量，避免 results 在追加过程中多次扩容。
	results := make([]SignedItem, 0, len(messages))
	for _, text := range messages {
		// 每条消息只做一次字符串到字节的转换；不要在 Sign 前后反复转换。
		message := []byte(text)
		// Sign 的签名切片由标准库返回，外围只能减少额外容器分配。
		signature := ed25519.Sign(privateKey, message)
		results = append(results, SignedItem{
			Message:   message,
			Signature: signature,
		})
	}
	return results
}

func printableSignature(signature []byte) string {
	// 只有文本协议需要时才做 Base64，避免热循环无条件创建编码字符串。
	return base64.RawStdEncoding.EncodeToString(signature)
}

func demoBatch(privateKey ed25519.PrivateKey) {
	items := signBatch(privateKey, []string{"a", "b", "c"})
	for _, item := range items {
		// 展示层才编码，业务层仍保留原始签名字节。
		fmt.Println(printableSignature(item.Signature))
	}
}

这段写法没有承诺“零分配”：[]byte(text) 会创建消息字节，ed25519.Sign 也会返回新的签名切片。它做的是把结果容器容量一次设好，把消息转换控制在一次，把 Base64 从签名热路径中移出去。

方案选择：直接返回签名，还是保留批处理记录

如果下游立即发送签名，函数可以只返回 [][]byte，减少结构体字段；如果后面还要审计原文、记录消息 ID 或异步验签，保留 SignedItem 更容易维护。这里没有绝对的“最快写法”，要看数据生命周期和所有权边界。

尤其要注意，不能为了“复用”而在下一轮覆盖仍被异步任务引用的消息切片。切片复用只有在所有消费者完成后才安全；若生命周期不清楚，宁可保留独立切片，也不要引入数据竞争或签名内容被改写的问题。

失败分支：密钥长度、消息变化和错误的优化目标

Sign 在私钥长度不正确时会 panic，Verify 在公钥长度不正确时也会 panic。来自文件、网络或配置的密钥不要直接信任长度，至少在进入核心调用前按 ed25519.PrivateKeySize 和 ed25519.PublicKeySize 做边界处理。签名验证失败则应当作为普通业务分支返回，不要把失败消息继续送入后续流程。

func verifyOne(publicKey ed25519.PublicKey, message, signature []byte) error {
	// 外部输入先检查长度，避免把不可信数据直接传给会 panic 的 API。
	if len(publicKey) != ed25519.PublicKeySize {
		return fmt.Errorf("公钥长度错误: %d", len(publicKey))
	}
	if !ed25519.Verify(publicKey, message, signature) {
		// 验签失败表示当前消息与签名不匹配，不等于系统异常。
		return errors.New("签名验证失败")
	}
	return nil
}

代码片段假设文件已经导入 errors、fmt 和 crypto/ed25519。更重要的是不要为了节省一次分配而复用错误的消息缓存：安全边界和数据所有权比一次小的切片创建更优先。

落地清单：先保证正确，再量化分配

1. 把密钥生成移到批处理循环外，私钥只交给签名端，公钥交给验签端。
2. 固定消息的字节表示，保证签名和验证看到的内容完全一致。
3. 用 make([]T, 0, len(input)) 预分配结果容器，减少扩容。
4. Base64、JSON 或日志格式化放到真正需要文本的边界，不要污染签名热循环。
5. 保留对 Sign 新签名切片的现实预期，再用基准测试确认优化收益。
6. 外部密钥先检查长度，验签失败直接结束当前项，不把失败数据继续传播。

可以把这篇的判断压缩成一句话：ed25519 先用同一份字节完成 Sign/Verify，再把可控的转换、扩容和编码分配移出循环；不要把标准库返回签名的固定成本误写成零分配。

相关问题

短消息要先做 SHA-256 再调用 ed25519.Sign 吗？

普通 Ed25519 使用原始消息即可，是否预哈希取决于协议约定，不应为了减少分配随意改变签名输入。双方必须使用同一套规则。

为什么 Verify 只有 bool，没有 error？

普通 Verify 用布尔值表达签名是否匹配；如果使用带上下文或预哈希变体，可以根据官方 API 选择 VerifyWithOptions，但仍需遵守双方一致的消息和选项约定。

能不能把一块固定数组传给 Sign 让它写入？

Sign 的 API 返回签名切片，没有提供调用方输出缓冲区参数。因此可以优化外围容器和编码，但不能把它改造成由调用方提供签名目标缓冲区的接口。