Go crypto/ecdh ECDH 返回曲线不匹配错误怎么办

你在使用Go标准库crypto/ecdh做椭圆曲线密钥协商时碰到返回曲线不匹配错误，一般是协商两端的密钥来自不同的椭圆曲线类型，优先核对两端生成公私钥所用的曲线标识，统一为同一种曲线规格就能解决绝大多数场景的这类问题。

Go 的 crypto/ecdh 报曲线不匹配时，先不要把问题归结为“公钥坏了”。最常见的原因是：本地 PrivateKey 来自一条曲线，而远端 PublicKey 按另一条曲线生成或解析。把双方的曲线选择集中管理，并在调用 ECDH 前检查，通常就能定位问题。

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

修复的关键不是修改共享秘密，而是让本地私钥、远端公钥和调用 ECDH 的 Curve 形成同一条配置链。P256、P384、P521 和 X25519 不能混用；公钥字节解析失败则是另一个更早的错误边界。

先区分两类错误

PrivateKey.ECDH(remote) 要求私钥和远端公钥使用同一条曲线。比如本地用 ecdh.P256() 生成密钥，却把按 ecdh.P384() 生成的公钥传进来，调用就不满足前置条件。另一方面，若远端字节根本不是目标曲线接受的编码，错误会出现在 Curve.NewPublicKey，还没有走到 ECDH。

排查时先记录“在哪一步失败”：NewPublicKey 返回错误，优先看公钥编码和选用的解析曲线；ECDH 返回错误，优先看两端曲线是否一致。不要只打印公钥字节，更不要记录私钥。

把 Curve 选择固定在同一个入口

生产代码不宜在生成本地密钥、解析远端公钥和执行交换时分别调用不同的曲线函数。可以让构造函数接收一个 ecdh.Curve，后续所有动作都引用它。下面的示例只演示曲线一致性，不包含密钥派生和消息加密。

package main

import (
	"crypto/ecdh"
	"crypto/rand"
	"fmt"
)

// newKeyPair 使用调用方传入的曲线，避免生成阶段偷偷换曲线。
func newKeyPair(curve ecdh.Curve) (*ecdh.PrivateKey, error) {
	// GenerateKey 会返回与 curve 绑定的私钥和公钥。
	return curve.GenerateKey(rand.Reader)
}

func main() {
	// 曲线选择集中在一个变量，通信双方的配置应采用同样的约定。
	curve := ecdh.P256()
	privateKey, err := newKeyPair(curve)
	if err != nil {
		// 生成失败时保留上下文，避免把错误伪装成网络问题。
		panic(fmt.Errorf("生成 ECDH 私钥失败: %w", err))
	}

	// 这里的 publicKey 只用于展示本地曲线边界，实际项目通常来自远端。
	publicKey := privateKey.PublicKey()
	if publicKey.Curve() != curve {
		// Curve 实例可直接比较，便于在调用 ECDH 前快速拦截配置错误。
		panic("本地公钥与配置曲线不一致")
	}
	fmt.Println("曲线配置已固定")
}

如果项目支持多种曲线，建议把曲线名称作为受控配置映射到有限的构造函数，而不是让网络请求携带任意曲线对象。这样可以在启动时检查配置，在握手时只传递公钥和协商结果。

接收远端公钥时使用同一条曲线解析

PublicKey 通常来自网络。正确顺序是先按协议约定选择 Curve，再调用该 Curve 的 NewPublicKey 解析字节。NIST 曲线使用未压缩点编码；X25519 的检查边界不同，不能把一种曲线的字节格式套到另一种曲线上。

package ecdhdemo

import (
	"crypto/ecdh"
	"fmt"
)

// parsePeerKey 只负责按协议约定的曲线解析远端公钥。
func parsePeerKey(curve ecdh.Curve, encoded []byte) (*ecdh.PublicKey, error) {
	// NewPublicKey 同时承担长度和曲线编码的基础检查。
	peer, err := curve.NewPublicKey(encoded)
	if err != nil {
		// 不记录完整公钥内容；错误上下文足够定位解析阶段。
		return nil, fmt.Errorf("按协商曲线解析远端公钥失败: %w", err)
	}
	return peer, nil
}

func exchange(local *ecdh.PrivateKey, peerBytes []byte) ([]byte, error) {
	// 从本地私钥取得唯一可信的曲线，避免调用方另传一条曲线。
	curve := local.Curve()
	peer, err := parsePeerKey(curve, peerBytes)
	if err != nil {
		return nil, err
	}

	// ECDH 会再次要求本地私钥和远端公钥使用相同曲线。
	secret, err := local.ECDH(peer)
	if err != nil {
		return nil, fmt.Errorf("执行 ECDH 失败: %w", err)
	}
	return secret, nil
}

这个写法把解析曲线绑定到 local.Curve()，能减少“本地生成用 P256、接收解析用 P384”的分叉。若协议本身带有曲线标识，应先把标识映射为受控的 ecdh.Curve，再创建本地私钥；不要仅凭公钥长度猜曲线。

调用 ECDH 前做一次轻量检查

排查现有代码时，可以把检查放在交换函数入口，快速把错误归因到“曲线选择”而不是网络、Base64 或后续加密。Curve() 返回曲线接口；标准库文档说明，同一条曲线的多次调用会返回可用于相等判断的值，因此可以直接比较。

func checkedECDH(local *ecdh.PrivateKey, peer *ecdh.PublicKey) ([]byte, error) {
	// 先拦截配置不一致，避免把错误拖到更深的协议层。
	if local == nil || peer == nil {
		return nil, fmt.Errorf("ECDH 密钥不能为空")
	}
	if local.Curve() != peer.Curve() {
		// 日志只记录曲线名称或受控编号，不记录私钥和完整公钥。
		return nil, fmt.Errorf("ECDH 曲线不匹配: local=%v remote=%v", local.Curve(), peer.Curve())
	}

	// 通过检查后再调用标准库执行共享秘密计算。
	secret, err := local.ECDH(peer)
	if err != nil {
		return nil, fmt.Errorf("ECDH 交换失败: %w", err)
	}
	return secret, nil
}

这段检查用于尽早暴露配置错误，不是对密码学安全性的替代。共享秘密拿到后仍应进入项目既有的密钥派生流程，不能直接当作消息加密密钥使用。

生产环境的曲线排查清单

常见问题

把 P256 的私钥和 P384 的公钥转换一下能解决吗？

不能把它们当成同一对密钥直接转换。应按协议重新选择同一条曲线并重新生成或正确解析双方密钥，避免把格式转换误当成曲线协商。

NewPublicKey 成功了，为什么 ECDH 仍然失败？

解析成功只说明输入满足调用该 Curve 的基础编码检查。还要确认传入 ECDH 的远端公钥确实是按本地私钥的 Curve 解析得到的，并检查 X25519 的全零结果等运行时错误。

可以只比较公钥字节长度吗？

不可以。不同曲线可能有不同编码规则，长度也不是协议身份。应在配置层保存曲线标识，在 API 边界使用 Curve() 和 NewPublicKey 表达约束。

总的来说，Go crypto/ecdh 的曲线不匹配要在“曲线选择—密钥生成—公钥解析—ECDH 调用”这条链上排查。把 Curve 固定到一个可信入口，接收公钥时复用它，并在交换前保留明确的错误上下文，就能把这类问题从模糊的握手失败变成可定位的配置错误。