Go crypto/ecdh 公钥编码与曲线类型转换

Go 的 crypto/ecdh 公钥需要按实际格式处理：PublicKey.Bytes() 的原始编码交给约定曲线的 NewPublicKey；PKIX DER 则交给 x509.ParsePKIXPublicKey。NIST 曲线解析出的 *ecdsa.PublicKey 可通过 ECDH() 转成 ECDH 对象，但这不会把 P-256 公钥转换成 X25519 公钥。

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

先限定失败发生在哪一层

考虑一个跨服务集成场景：发送方把公钥改为 PEM 文本，接收方仍把整段文本传给 P256().NewPublicKey。后来接收方增加了 PKIX 解析，却直接断言结果为 *ecdh.PublicKey，又遇到类型不匹配。这是用于说明问题的假设案例，不是生产事故记录。

排查顺序应从双方约定开始：传输内容是原始字节、Base64 包装的原始字节，还是 PEM 包装的 DER？接收方预期哪条曲线？解析后得到哪种 Go 类型？格式错误、类型不匹配与曲线不一致可以发生在不同层，不能都归结为“公钥不合法”。

原始公钥必须交给约定曲线解析

原始格式没有通用的自描述容器，接收方应从接口协议取得曲线名，不能反复尝试不同曲线，直到某次解析成功。下面代码建立有限白名单，并让格式错误停留在解析层。

package peerkey

import (
    "crypto/ecdh"
    "fmt"
)

// CurveByName 只接受协议明确约定的曲线，不根据公钥长度猜测。
func CurveByName(name string) (ecdh.Curve, error) {
    switch name {
    case "P-256":
        return ecdh.P256(), nil
    case "P-384":
        return ecdh.P384(), nil
    case "P-521":
        return ecdh.P521(), nil
    case "X25519":
        return ecdh.X25519(), nil
    default:
        return nil, fmt.Errorf("不支持的公钥曲线: %q", name)
    }
}

func ParseRawPeer(name string, raw []byte) (*ecdh.PublicKey, error) {
    curve, err := CurveByName(name)
    if err != nil {
        return nil, err
    }
    // raw 必须是约定曲线的原始公钥编码，不是 PEM 或 SPKI DER。
    pub, err := curve.NewPublicKey(raw)
    if err != nil {
        return nil, fmt.Errorf("原始公钥解析失败: %w", err)
    }
    return pub, nil
}

NIST 曲线的 NewPublicKey 要求未压缩点编码，不接受压缩点和无穷远点；X25519 的解析检查重点是坐标编码长度，因此解析成功不代表后续共享秘密运算一定成功。不要把 X25519 的字节当成另一条曲线的点重新解释。

PUBLIC KEY 容器先解析再转换对象

PKIX 公钥是 SubjectPublicKeyInfo 结构，通常放在 PUBLIC KEY 类型的 PEM 块里。ParsePKIXPublicKey 返回通用接口，NIST 曲线公钥通常表现为 *ecdsa.PublicKey，X25519 公钥则表现为 *ecdh.PublicKey。接收逻辑应使用类型分支，不使用可能 panic 的单值断言。

// 本段放入同一个 peerkey 包，需补充 bytes、crypto/ecdsa、
// crypto/x509、encoding/pem 导入，并保留前段的 ecdh、fmt 导入。
func ParsePEMPeer(data []byte, wantCurve string) (*ecdh.PublicKey, error) {
    want, err := CurveByName(wantCurve)
    if err != nil {
        return nil, err
    }
    block, rest := pem.Decode(data)
    if block == nil || block.Type != "PUBLIC KEY" {
        return nil, fmt.Errorf("需要 PUBLIC KEY 类型的 PEM 公钥")
    }
    // 本接口只接收一个公钥块，不接受尾随证书或其他数据。
    if len(bytes.TrimSpace(rest)) != 0 {
        return nil, fmt.Errorf("公钥块后存在额外内容")
    }
    decoded, err := x509.ParsePKIXPublicKey(block.Bytes)
    if err != nil {
        return nil, fmt.Errorf("SPKI 公钥解析失败: %w", err)
    }

    var pub *ecdh.PublicKey
    switch key := decoded.(type) {
    case *ecdh.PublicKey:
        pub = key
    case *ecdsa.PublicKey:
        // NIST 公钥保留原曲线，转换不受支持时返回错误。
        pub, err = key.ECDH()
        if err != nil {
            return nil, fmt.Errorf("公钥不能用于 ECDH: %w", err)
        }
    default:
        return nil, fmt.Errorf("不支持的公钥对象类型: %T", decoded)
    }
    if pub.Curve() != want {
        return nil, fmt.Errorf("公钥曲线不符合接口约定 %q", wantCurve)
    }
    return pub, nil
}

这里的 ECDH() 是公钥对象方法，不需要私钥，也不计算共享秘密。它会拒绝不支持的曲线或无效公钥。PEM 的文字标签也不保证块内就是目标算法，所以仍需检查解析结果和 Curve()。示例接收 PUBLIC KEY 公钥，不接收 CERTIFICATE 证书块，也不接收 RSA PUBLIC KEY 格式。

需要向外导出 PEM 时，应先构造 SPKI DER。不能把原始 Bytes() 直接放进 PUBLIC KEY 块并期待 PKIX 解析器识别。

// 与前述代码使用相同包和导入；仅序列化公钥，不输出私钥。
func EncodePeerPEM(pub *ecdh.PublicKey) ([]byte, error) {
    if pub == nil {
        return nil, fmt.Errorf("公钥不能为空")
    }
    der, err := x509.MarshalPKIXPublicKey(pub)
    if err != nil {
        return nil, fmt.Errorf("公钥序列化失败: %w", err)
    }
    return pem.EncodeToMemory(&pem.Block{
        Type:  "PUBLIC KEY",
        Bytes: der,
    }), nil
}

这几段是同一辅助包中的示例函数，未附带真实公钥、私钥、交换结果或本机运行记录。调用者传入实际数据，接收返回的公钥或错误。

类型转换不会把 P-256 改成 X25519

从 ECDSA 公钥对象转换到 ECDH 公钥对象，保留的是同一个受支持曲线上的公钥点。P-256、P-384、P-521 与 X25519 是不同曲线选择，不能靠类型断言、换 PEM 标签或重新包装字节改变。若通信协议决定切换曲线，需要双方使用相应的新密钥并同步协议约定。

公钥对象上的 ECDH() 与私钥对象上的 ECDH(remote) 也要区分：前者转换对象表示，后者进行共享秘密计算。实际计算要求双方密钥使用相同曲线；即使 X25519 公钥解析通过，产生全零结果的输入仍会让运算返回错误。

把格式约定保存在接口契约里

在上面的集成案例中，修复点不是删除公钥校验，而是让发送与接收使用同一格式约定，并对解析结果做显式类型处理。接口至少说明曲线、字节格式、文本包装和允许的 PEM 块类型。错误反馈可以保留“文本解码”“SPKI 解析”“对象类型”“曲线不一致”等层次，避免只返回一个无法定位的失败提示。

为什么同一公钥往返 PKIX 后 Go 类型变了？容器存储的是算法及公钥数据，不承诺保留发送方的 Go 对象类型。NIST ECDH 公钥解析后通过 ECDSA 公钥对象承载，是需要显式转换的正常情况。

改成压缩点能缩小传输吗？不能直接用于这里的 NIST NewPublicKey 入口；该入口拒绝压缩编码。应遵守双方协议及实际解析接口支持的格式。

解析成功就表示对端可信了吗？解析解决格式与对象构造问题，不证明对端身份。本文的函数也不是完整的认证密钥交换协议。

参考：crypto/ecdh 接口、PKIX 公钥解析、ECDSA 公钥的 ECDH 转换。