当前位置：首页 > 文章列表 > Golang > Go教程 > Go crypto/ecdh 密钥交换怎么落地：公钥序列化与共享密钥一致性

Go crypto/ecdh 密钥交换怎么落地：公钥序列化与共享密钥一致性

来源：17golang原创 2026-08-27 16:26:00 0浏览收藏

Go 标准库的 crypto/ecdh 已经把椭圆曲线 Diffie-Hellman 的密钥生成、公钥导出和共享秘密计算收进了清晰的 API。真正容易出错的地方不在生成密钥，而在公钥经过网络传输后如何恢复，以及双方如何确认算出的共享字节确实一致。

落地时固定一条链路：双方各自用同一条曲线生成私钥，发送 PublicKey.Bytes()，接收端用同一条曲线的 NewPublicKey 恢复公钥，再调用 PrivateKey.ECDH；共享结果还要经过 KDF 和协议校验，不能直接当成业务密文。

要点速览

PublicKey.Bytes() 是传输用的字节表示，不是可以跳过曲线校验的裸数据。
NewPublicKey 负责把收到的字节恢复成指定曲线的公钥，格式错误会返回错误。
双方分别计算出的共享秘密应做等长和字节一致性验收。
ECDH 只解决共享秘密协商，后续仍需要 KDF、认证和对称加密协议。

crypto/ecdh 解决的是哪一段问题

ECDH 的目标是让两端在不直接发送私钥的情况下得到同一段共享秘密。A 保留自己的私钥，把公钥发给 B；B 做同样的事。A 用自己的私钥和 B 的公钥计算，B 用自己的私钥和 A 的公钥计算，双方得到的字节应相同。

Go 的 crypto/ecdh 把这个流程拆成几个可检查的对象：ecdh.Curve 生成 PrivateKey，私钥导出 PublicKey，公钥导出字节，另一端再由曲线恢复公钥。对象边界清楚，反而更适合在协议代码里写显式校验。

先把公钥变成可传输的字节

下面的函数只负责生成一方密钥并导出公钥。示例选择 ecdh.P256()，重点是把“生成”和“传输表示”分开，网络层拿到的是 []byte，私钥不会离开本端。

package main

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

func makeKeyPair() (*ecdh.PrivateKey, []byte, error) {
    curve := ecdh.P256()
    privateKey, err := curve.GenerateKey(rand.Reader)
    if err != nil {
        return nil, nil, err
    }
    publicBytes := privateKey.PublicKey().Bytes()
    return privateKey, publicBytes, nil
}

func main() {
    privateKey, publicBytes, err := makeKeyPair()
    if err != nil {
        panic(err)
    }
    restored, err := ecdh.P256().NewPublicKey(publicBytes)
    if err != nil {
        panic(err)
    }
    fmt.Println(privateKey.PublicKey().Equal(restored))
}

这里的输出不能直接照抄成“必然为 true”：NewPublicKey 返回两个值，真实代码要先检查错误。示例的关键路径是 GenerateKey → PublicKey → Bytes，后续接收方必须沿相反方向恢复对象。

Go crypto/ecdh 从 P256 GenerateKey 到 PublicKey Bytes，再由 NewPublicKey 恢复公钥的控制流逻辑图

接收端要用同一条曲线恢复公钥

网络传输后的公钥只是字节切片，不能把它强行转换成另一个曲线的公钥对象。接收方应保留协议约定的曲线，在这条曲线上调用 NewPublicKey，并把错误当成输入校验失败处理。

func restorePeerPublicKey(publicBytes []byte) (*ecdh.PublicKey, error) {
    curve := ecdh.P256()
    peerPublicKey, err := curve.NewPublicKey(publicBytes)
    if err != nil {
        return nil, fmt.Errorf("restore peer public key: %w", err)
    }
    return peerPublicKey, nil
}

不要只判断字节长度。长度检查最多是快速拒绝明显异常输入，格式和曲线有效性仍由 NewPublicKey 完成。恢复成功后，公钥才进入 ECDH 计算链路。

双方 ECDH 计算后怎样验收一致性

为了让测试不依赖网络，下面把 A、B 两端的公钥字节在内存中互换。A 使用 privateA 和恢复后的 publicB，B 使用 privateB 和恢复后的 publicA。两次调用返回的共享秘密需要逐字节比较。

func exchange() error {
    curve := ecdh.P256()
    privateA, err := curve.GenerateKey(rand.Reader)
    if err != nil {
        return err
    }
    privateB, err := curve.GenerateKey(rand.Reader)
    if err != nil {
        return err
    }

    publicABytes := privateA.PublicKey().Bytes()
    publicBBytes := privateB.PublicKey().Bytes()
    publicA, err := curve.NewPublicKey(publicABytes)
    if err != nil {
        return err
    }
    publicB, err := curve.NewPublicKey(publicBBytes)
    if err != nil {
        return err
    }

    sharedA, err := privateA.ECDH(publicB)
    if err != nil {
        return err
    }
    sharedB, err := privateB.ECDH(publicA)
    if err != nil {
        return err
    }
    if !bytes.Equal(sharedA, sharedB) {
        return errors.New("shared secret mismatch")
    }
    return nil
}

这段验收关注的是调用链和结果，而不是打印共享秘密。生产日志不要输出私钥、公钥原文或共享秘密；测试中也更适合比较结果后只报告“匹配”或“失败”。

Go crypto/ecdh 双方交换公钥后分别调用 PrivateKey ECDH，最后比较 sharedA 与 sharedB 的一致性逻辑图

和手写旧方案相比，边界更集中

手写 ECDH 流程往往把曲线参数、公钥编码和错误处理散落在多个函数里。crypto/ecdh 让曲线对象成为入口：生成、恢复和计算都从同一个 Curve 出发，调用方更容易把协议中的曲线选择固定下来。

检查点	推荐做法	不要做
曲线	双方明确约定 `ecdh.P256()` 等同一入口	一端生成后让另一端猜曲线
公钥传输	发送 `PublicKey.Bytes()`，接收后调用 `NewPublicKey`	把任意字节直接当作已验证公钥
共享结果	比较长度和字节，再交给 KDF	直接打印或直接当业务密文

采用前要补上的安全边界

ECDH 只提供密钥协商，不自动认证对端。攻击者如果能替换双方公钥，仍可能把连接拆成两段，所以实际协议还需要证书、签名或预共享身份信息来认证公钥来源。

共享秘密也不应直接作为 AES-GCM 等算法的最终密钥。通常要经过带上下文和双方随机数的 KDF，再把派生结果交给经过认证的对称加密方案。协议升级时，曲线名称、编码格式、KDF 参数和身份绑定都应写进版本化的握手结构，而不是藏在默认值里。

验收结论

一篇可维护的 Go ECDH 实现，最少要能回答四个问题：用的哪条曲线、公钥如何序列化、接收端如何恢复、双方如何证明共享结果一致。把 GenerateKey、PublicKey.Bytes、NewPublicKey 和 ECDH 串成显式链路，再把认证与 KDF 放进协议设计，代码才从“能算出结果”走到“能上线验收”。