Go crypto/ecdh.NewPublicKey 怎样从字节构造公钥

在 Go 里，网络协议或序列化数据通常只会给你一段对端公钥字节。要把它变成可以传给 PrivateKey.ECDH 的公钥对象，应该先选择同一条 ecdh.Curve，再调用它的 NewPublicKey 方法。解析成功得到 *ecdh.PublicKey，失败则返回错误；不要把未经检查的字节直接当成有效公钥。

核心做法是“曲线先固定，字节再解析”：NIST 曲线要求未压缩点编码，X25519 只检查 u 坐标长度，解析错误必须作为不可信对端输入处理。

参考文档：https://pkg.go.dev/crypto/ecdh#Curve.NewPublicKey

本文只讲公钥字节到 PublicKey 的导入边界，不展开完整握手协议、证书链或私钥保存方案。

先区分曲线与公钥字节格式

crypto/ecdh 把曲线作为接口提供：可以使用 ecdh.P256()、ecdh.P384()、ecdh.P521() 或 ecdh.X25519()。同一段字节在不同曲线下没有通用解释，调用方必须先从协议字段、配置或协商结果中确定曲线。

对于 NIST 曲线，NewPublicKey 按 SEC 1 的未压缩点格式解码，压缩编码和无穷远点会被拒绝。对于 X25519，方法只检查 u 坐标的长度；这不等于任何字节都能安全完成密钥交换，文档还特别提示某些对端公钥可能让后续 ECDH 返回错误。

用 NewPublicKey 把字节解析成公钥

下面的函数把“曲线选择”和“公钥解析”放在同一个边界内。真实项目里，encoded 可以来自协议报文，但应先按报文长度或上限做基础检查，避免把任意大输入直接交给密码学代码。

package main

import (
    "crypto/ecdh"
    "fmt"
)

// parsePeerPublicKey 只负责把指定曲线下的字节解析成 PublicKey。
func parsePeerPublicKey(curve ecdh.Curve, encoded []byte) (*ecdh.PublicKey, error) {
    // 先拒绝空输入，避免把明显的协议错误交给更深层逻辑。
    if len(encoded) == 0 {
        return nil, fmt.Errorf("对端公钥为空")
    }

    // NewPublicKey 会按 curve 的规则校验编码并返回解析错误。
    publicKey, err := curve.NewPublicKey(encoded)
    if err != nil {
        return nil, fmt.Errorf("解析对端公钥失败: %w", err)
    }
    return publicKey, nil
}

func main() {
    // 曲线必须来自协议约定，示例用 P-256 表示一个固定选择。
    peer, err := parsePeerPublicKey(ecdh.P256(), []byte{
        // 这里只放示意字节；生产代码应使用协议收到的完整编码。
        0x04, 0x01, 0x02,
    })
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println("曲线:", peer.Curve())
}

示例没有把短字节伪装成有效结果：P-256 的示意输入会被解析器拒绝，调用方应记录错误并终止当前握手或请求。这里的重点是边界位置，而不是手写一组可以用于真实通信的公钥。

解析失败时先看哪一层

NewPublicKey 返回错误，通常说明输入不符合所选曲线的编码规则。排查时按下面三层区分，错误信息会比简单写成“公钥无效”更容易定位：

• 协议层：确认报文是否真的携带了公钥字段，是否在传输或 Base64 解码时被截断。
• 曲线层：确认本地选择的曲线与对端编码约定一致，不能用 X25519 的 32 字节输入去调用 P-256。
• 密码学编码层：NIST 曲线要检查未压缩点前缀、坐标长度和点是否在曲线上；X25519 还要把后续 ECDH 返回的错误纳入处理。

不要为了“让解析通过”去补零、截断或改写收到的字节。公钥属于对端输入，正确的失败策略是拒绝当前输入，并把必要的上下文交给上层协议处理。

解析后再确认 ECDH 的曲线边界

解析成功只说明字节符合某条曲线的公钥表示，不代表已经完成密钥交换。真正调用 privateKey.ECDH(peer) 时，本地私钥和对端公钥必须使用同一条曲线；X25519 还可能因为对端公钥导致共享结果无效而返回错误。

func deriveSharedSecret(privateKey *ecdh.PrivateKey, encoded []byte) ([]byte, error) {
    // 先从私钥取得曲线，保证公钥解析使用同一条曲线。
    peer, err := privateKey.Curve().NewPublicKey(encoded)
    if err != nil {
        return nil, fmt.Errorf("对端公钥格式错误: %w", err)
    }

    // ECDH 仍可能失败，尤其不能把错误结果当成可用共享秘密。
    secret, err := privateKey.ECDH(peer)
    if err != nil {
        return nil, fmt.Errorf("ECDH 计算失败: %w", err)
    }
    return secret, nil
}

这个边界还有一个好处：调用方不需要自己判断公钥的内部字段。PublicKey 的字段是不透明的，继续使用公开方法 Curve、Bytes 和 ECDH 即可。

相关问题

为什么不能直接把公钥字节转成结构体？因为编码合法性和曲线规则由 Curve.NewPublicKey 统一检查，直接转换无法替代这些检查。

同样长度的公钥字节能跨曲线复用吗？不能。长度只是基础条件，编码格式、曲线和点的合法性都必须匹配。

解析成功后还需要检查 ECDH 错误吗？需要。解析和共享秘密计算是两个阶段，尤其 X25519 的 ECDH 仍可能因对端公钥返回错误。