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

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

落地时固定一条链路：双方各自用同一条曲线生成私钥，发送 PublicKey.Bytes()，接收端用同一条曲线的 NewPublicKey 恢复公钥，再调用 PrivateKey.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，后续接收方必须沿相反方向恢复对象。

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

网络传输后的公钥只是字节切片，不能把它强行转换成另一个曲线的公钥对象。接收方应保留协议约定的曲线，在这条曲线上调用 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
}

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

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

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

采用前要补上的安全边界

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

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

相关问题

PublicKey.Bytes() 能不能直接保存成字符串？

可以把字节编码为 Base64 或十六进制用于文本协议，但接收后仍要还原字节并调用同一曲线的 NewPublicKey，编码只是传输层选择。

两端共享秘密不一致先查哪里？

先确认两端交换的公钥没有串位，再确认曲线一致，接着检查恢复后的公钥是否来自对应字节。不要先怀疑随机数，因为双方使用的是不同私钥，结果一致依赖的是 ECDH 调用的对象配对。

ECDH 返回的共享字节可以直接发给前端吗？

不建议。共享秘密属于密钥材料，应该留在受保护的协议边界内，通过 KDF 和认证加密使用，避免出现在日志、响应体或调试页面中。

验收结论

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