Go ECDH 私钥曲线不一致为什么无法计算共享密钥

因为 ECDH 不是“任意椭圆曲线私钥乘任意公钥”。本地私钥和对端公钥必须属于同一个 Curve，双方才在同一组参数、同一基点和同一群运算规则下计算同一个共享秘密。Go 的 (*ecdh.PrivateKey).ECDH 明确要求两把密钥使用相同曲线；拿 P-256 私钥去计算 P-384 或 X25519 公钥，会直接返回错误，不会替你转换曲线。

Go 标准库文档：https://pkg.go.dev/crypto/ecdh

一、这个限制来自 ECDH 的计算前提

crypto/ecdh 支持 NIST P-256、P-384、P-521 和 X25519。它们不是同一曲线的不同长度版本，而是不同的参数集合。私钥标量的合法范围、公钥点编码、曲线方程和共享秘密计算规则都与具体曲线绑定。

因此，曲线不一致不是“安全强度稍有差别”，而是输入对象根本不属于同一个运算域。Go 在 API 边界拒绝这次交换，比尝试猜测或转换更安全。PrivateKey.Curve() 和 PublicKey.Curve() 就是排查这类问题最直接的入口。

二、最小示例：P-256 私钥配 P-384 公钥

下面故意让 Alice 生成 P-256 私钥，让 Bob 生成 P-384 密钥，然后把 Bob 的公钥交给 Alice。代码只用来复现边界，重点看错误是否出现，不要把失败误判成随机数问题或公钥损坏。

package main

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

func main() {
	// Alice 使用 P-256 生成本地私钥
	alicePrivate, err := ecdh.P256().GenerateKey(rand.Reader)
	if err != nil {
		log.Fatal(err)
	}

	// Bob 故意使用 P-384，制造曲线不一致的对端公钥
	bobPrivate, err := ecdh.P384().GenerateKey(rand.Reader)
	if err != nil {
		log.Fatal(err)
	}

	// ECDH 会拒绝 P-256 私钥与 P-384 公钥的组合
	_, err = alicePrivate.ECDH(bobPrivate.PublicKey())
	fmt.Printf("曲线不一致是否返回错误：%v\n", err != nil)
}

这里的关键不是私钥之间不同，而是 Alice 的私钥曲线与传入的 Bob 公钥曲线不同。正常 ECDH 本来就要求双方拥有不同的私钥；只要曲线一致，双方仍能分别算出相同的共享秘密。

三、修复方式：先统一曲线，再计算两边的秘密值

最小修复是让双方都使用协议约定的同一曲线，并在调用前做一次显式检查。Go 返回的 Curve 值可以用于相等比较，因此可以把模糊的底层错误提前转换成更清楚的业务错误。

package main

import (
	"bytes"
	"crypto/ecdh"
	"crypto/rand"
	"errors"
	"fmt"
	"log"
)

func derive(private *ecdh.PrivateKey, peer *ecdh.PublicKey) ([]byte, error) {
	// 在进入 ECDH 前确认双方密钥属于同一 Curve
	if private.Curve() != peer.Curve() {
		return nil, errors.New("ECDH 曲线不一致")
	}
	return private.ECDH(peer)
}

func main() {
	curve := ecdh.P256() // 双方从同一协议配置取得曲线
	alice, err := curve.GenerateKey(rand.Reader)
	if err != nil {
		log.Fatal(err)
	}
	bob, err := curve.GenerateKey(rand.Reader)
	if err != nil {
		log.Fatal(err)
	}

	// 双方分别使用自己的私钥和对方的公钥
	secretA, err := derive(alice, bob.PublicKey())
	if err != nil {
		log.Fatal(err)
	}
	secretB, err := derive(bob, alice.PublicKey())
	if err != nil {
		log.Fatal(err)
	}

	fmt.Printf("双方共享秘密一致：%v\n", bytes.Equal(secretA, secretB))
}

示例中的共享秘密是 ECDH 原始输出。真实协议通常还要把它交给经过设计的密钥派生过程，并绑定握手上下文；不要直接把原始字节当成长期加密密钥。

四、跨服务传公钥时，曲线信息不能丢

很多线上问题不发生在生成密钥时，而发生在序列化边界：服务 A 只传 PublicKey.Bytes()，服务 B 默认用另一条曲线调用 NewPublicKey。即使字节长度检查碰巧通过，也不代表协议语义正确。

更稳妥的消息结构应包含协议版本、允许列表中的曲线标识和公钥字节。接收方先根据曲线标识选择 ecdh.P256()、ecdh.P384()、ecdh.P521() 或 ecdh.X25519()，再调用该 Curve 的 NewPublicKey，最后确认它与本地私钥曲线相同。未知曲线应立即拒绝，不能静默回退。

五、相关问题

P-256 私钥可以转换成 P-384 私钥吗？

不能把现有私钥当作通用整数直接迁移。两条曲线的合法标量范围和公钥关系不同，应在目标曲线上重新生成密钥，并重新交换对应公钥。

X25519 公钥能交给 P-256 私钥计算吗？

不能。X25519 与 NIST P-256 使用不同曲线和编码规则，必须由同为 X25519 的私钥参与计算。

双方私钥不同，为什么还能得到同一个结果？

ECDH 的目标正是让双方用各自私钥与对方公钥得到相同共享秘密。要求相同的是曲线参数，不是私钥内容。