Go crypto/ecdh 两把不同曲线公钥做 ECDH 为什么会失败

在 Go 的 crypto/ecdh 中，两端都拿到了看似合法的密钥，PrivateKey.ECDH(remote) 仍然可能返回错误。最常见的根因不是随机数异常，而是本地私钥和远端公钥不属于同一条曲线：例如本地使用 P-256，远端公钥按 P-384 解析。

ECDH 的参与方必须先统一曲线。P-256、P-384、P-521 和 X25519 不是可以互换的参数；曲线不一致时，应在 ECDH 入口返回错误，而不是继续把结果交给密钥派生函数。

故障现场：密钥都能生成，交换却失败

这类问题通常出现在跨服务改造或协议字段新增之后：服务 A 默认调用 ecdh.P256()，服务 B 读取配置后切到了 ecdh.P384()。双方的密钥生成本身都可能成功，公钥也能序列化并传输；真正发生冲突的时刻，是一方用自己的私钥接收另一方公钥并调用 ECDH。

排查时先记录曲线名称，而不是记录私钥内容。PrivateKey.Curve() 和 PublicKey.Curve() 返回曲线对象；标准库文档明确要求 ECDH 的私钥与远端公钥使用同一曲线。私钥、远端公钥和调用点三者中，只要有一个沿途被换成另一条曲线，就应把它视为协议兼容问题。

先确认 ECDH 失败卡在哪个边界

不要先怀疑 KDF、密钥长度或网络传输。可以在不打印敏感材料的前提下，把曲线一致性放到调用前检查；下面的示例故意用 P-256 私钥和 P-384 公钥组成不兼容输入：

package main

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

func main() {
    // 两个参与方分别选择了不同曲线，模拟协议配置漂移。
    local, err := ecdh.P256().GenerateKey(rand.Reader)
    if err != nil {
        panic(err)
    }
    remote, err := ecdh.P384().GenerateKey(rand.Reader)
    if err != nil {
        panic(err)
    }

    // 先比较曲线，再执行 ECDH，避免把兼容错误带到后续处理。
    if local.Curve() != remote.PublicKey().Curve() {
        fmt.Println("curve mismatch: local=P256 remote=P384")
        return
    }
    secret, err := local.ECDH(remote.PublicKey())
    if err != nil {
        // ECDH 错误只记录边界信息，不打印私钥或共享秘密。
        panic(err)
    }
    fmt.Printf("shared secret length: %d\\n", len(secret))
}

这里的比较使用了曲线对象本身。P-256、P-384、P-521 和 X25519 的构造函数会返回可用于比较的曲线实现；如果检查失败，应该回到协议配置或密钥解析环节，而不是重试同一对输入。

根因：曲线选择没有成为协议的一部分

曲线名经常只存在于生成端的默认值里，公钥传输时却只发送了字节串。接收方于是按自己的默认曲线调用 NewPublicKey 或从证书解析公钥，最后才在 ECDH 入口暴露不一致。这个顺序会让日志看起来像“公钥有效但共享秘密失败”，实际缺失的是一条双方都遵守的曲线约定。

正确的边界是：协议先确定允许的曲线，生成端按约定生成密钥，传输格式保留足够的算法上下文，解析端只接受约定范围，进入 ECDH 前再检查一次。曲线名不是私密数据，可以作为版本化协议字段或配置项记录；私钥和共享秘密仍然不能进入日志。

修复动作：统一曲线，并把错误分层

修复这类故障可以按下面的顺序落地：

1. 在协议或配置中明确一条曲线，例如统一使用 P256，不要让两端各自选择默认值。
2. 生成密钥时使用同一个 ecdh.Curve；接收公钥时根据同一约定选择解析方式。
3. 调用 ECDH 前比较本地私钥和远端公钥的 Curve()，日志只保留曲线名和请求关联标识。
4. 把错误分成“公钥解析失败”“曲线不匹配”和“ECDH 计算失败”，不要把三类错误合并成一个重试。

如果协议确实要支持多条曲线，应该把曲线协商设计成明确的版本化字段，并规定双方选择结果；不能把 P-256 公钥转换成 P-384 公钥来“补救”。不同曲线代表不同的数学群和编码规则，换曲线意味着重新生成参与方密钥。

常见误区与复查清单

最后记住这个判断顺序：先看参与方曲线，再看公钥解析，最后才进入共享秘密之后的处理。只要本地私钥与远端公钥不是同一条曲线，crypto/ecdh 的失败就是合理的保护边界。

相关问题

• 为什么 P-256 和 P-384 不能只靠公钥字节长度兼容？因为编码长度不能替代曲线身份和数学参数。
• 曲线一致后还会失败吗？会，公钥解析、无效点或 X25519 的全零结果仍需单独处理。
• 能否在 ECDH 失败后换一条曲线重试？只有协议明确协商并重新生成密钥时才可以，不能复用原来的不匹配公钥。