Go crypto/ecdh 公钥 Bytes 怎么恢复为 PublicKey

我第一次把 ECDH 公钥放进消息里传输时，直觉是“收到 []byte 后直接还原”。真正容易漏掉的是：字节本身不携带曲线选择。Go 的 crypto/ecdh 给出的正确配对是导出端调用 PublicKey.Bytes()，接收端先根据协议选定同一条曲线，再调用它的 NewPublicKey。

这篇只讨论公钥字节编码与 PublicKey 的往返，不展开证书或 PKIX 封装。结论可以先记住：曲线标识和公钥字节要作为一个整体传输；恢复成功后再用 Equal 对照。

先确认 Bytes 到底保存了什么

PublicKey.Bytes() 返回的是公钥编码的一份副本，不是 Go 对象的内存地址，也不是一段可以脱离曲线解释的通用文本。对于 P-256、P-384、P-521 这类 NIST 曲线，NewPublicKey 按 SEC 1 的未压缩点格式解码；压缩点和无穷远点会被拒绝。

因此，协议字段至少应该有两部分：例如 curve: "P256" 和 public_key: []byte。如果只传 Base64 后的字节而丢了曲线名，接收方无法可靠判断应该调用 ecdh.P256() 还是其他曲线。

用同一条曲线把公钥恢复回来

下面用 P-256 做一个最小往返。生成端只负责导出公钥字节；恢复端拿到字节后使用同一条曲线的 NewPublicKey。示例中的 curveName 模拟协议里一起传来的曲线字段。

package main

import (
	"crypto/ecdh"
	"fmt"
)

func main() {
	curve := ecdh.P256()
	privateKey, err := curve.GenerateKey(nil)
	if err != nil {
		panic(err) // 示例直接终止；服务端应把错误转成可追踪的业务错误
	}

	// 只导出公钥编码；实际协议还要保存 curveName。
	publicBytes := privateKey.PublicKey().Bytes()
	curveName := "P256"

	// 接收端先按协议字段选择曲线，再解析公钥字节。
	if curveName != "P256" {
		panic("unsupported curve") // 不要猜测曲线，未知值应明确拒绝
	}
	restored, err := curve.NewPublicKey(publicBytes)
	if err != nil {
		panic(err) // 长度、点格式或曲线编码不符合要求时到这里
	}

	fmt.Println(restored.Curve() == curve)
	fmt.Println(restored.Equal(privateKey.PublicKey()))
}

预期的两个输出都是 true。这里的比较不是把两个 []byte 转成字符串，而是让 PublicKey.Equal 同时比较公钥类型、曲线和编码内容。Bytes() 返回副本也意味着调用方修改导出的切片，不应改变原来的公钥对象。

恢复失败时先看曲线和编码

排查时我会先看错误发生在 NewPublicKey 还是后面的 ECDH。NIST 曲线收到另一条曲线生成的字节，通常会在解析阶段因为长度或点不合法而失败；即使字节长度碰巧相同，也不能因此把它当成目标曲线的公钥。

另一个常见误区是把压缩点当成 NewPublicKey 的输入。官方接口对 NIST 曲线要求未压缩点编码，不能把其他库输出的压缩格式直接塞进来。协议双方应先约定 Go 需要的字节格式，或在边界层完成明确的格式转换，不能靠截断、补零或改首字节“修复”。

如果使用的是 ecdh.X25519()，规则不同：它检查的是 u 坐标长度，而不是 NIST 曲线的 SEC 1 未压缩点。不要把 P-256 的长度判断或首字节规则套到 X25519 上。解析成功也不等于后续交换一定成功，官方文档特别提示，经过对手选择的 X25519 公钥可能让 ECDH 返回错误。

把往返检查放在协议边界

如果公钥来自网络或外部存储，我建议把检查集中在反序列化函数里，而不是让业务层到处调用 NewPublicKey。至少记录三个结果：协议声明的曲线、字节长度、解析错误；不要把完整公钥写进普通日志。

func restorePeer(curve ecdh.Curve, wire []byte) (*ecdh.PublicKey, error) {
	// wire 只当作编码输入，不在这里猜测曲线或补齐长度。
	if len(wire) == 0 {
		return nil, fmt.Errorf("empty ECDH public key") // 空值应在业务层明确拒绝
	}
	key, err := curve.NewPublicKey(wire)
	if err != nil {
		return nil, fmt.Errorf("parse ECDH public key: %w", err) // 保留底层原因便于定位
	}
	return key, nil
}

在调用 ECDH 前，还要确认私钥和远端公钥来自同一条曲线。官方接口明确要求两者曲线一致；所以“解析成功”与“可以完成密钥交换”是两个检查点。对接其他语言时，优先交换协议规定的原始公钥编码，并为曲线名、编码格式和版本保留明确字段。

几个容易混淆的问题

Bytes 返回的是证书公钥吗？

不是。它是 crypto/ecdh.PublicKey 自己的公钥编码。证书或 PKIX 公钥属于另一层封装，不能把证书 DER 字节直接当成 Curve.NewPublicKey 的输入。

为什么 Equal 比较失败但 ECDH 似乎能工作？

官方文档提醒，不同编码可能表示等价的公钥；Equal 对曲线和编码做严格比较，而 ECDH 关注的是交换语义。协议内部最好统一一种编码，避免把“对象相等”和“可用于交换”混成一个判断。

最短排查顺序是什么？

先确认曲线字段没有丢失，再确认字节没有被 Base64/JSON 层错误处理，然后检查长度和编码类型，最后调用 NewPublicKey，成功后再检查 ECDH 的曲线一致性。这样能把传输问题、解析问题和交换问题分开。

总结

• PublicKey.Bytes() 导出的是公钥编码副本，曲线选择不会自动附加在字节里。
• NIST 曲线用同一条曲线的 NewPublicKey 恢复未压缩点；X25519 按自己的长度规则处理。
• 把曲线名、公钥编码和解析错误作为协议边界的一组信息，再用 Equal 与曲线一致性完成复查。