Go crypto/ecdh 私钥怎样用 Bytes 和 ParsePrivateKey 往返保存

crypto/ecdh.PrivateKey.Bytes() 导出的原始私钥编码，应通过对应曲线的 NewPrivateKey 恢复，例如 ecdh.P256().NewPrivateKey(raw)。crypto/ecdh 没有名为 ParsePrivateKey 的函数；搜索这个名字时，应先区分原始字节恢复与 x509 容器解析。

保存原始字节时，还要保存或由协议固定曲线。Bytes 不会替你生成一个自带曲线标识的通用密钥文件。本文用“格式版本、曲线名、Base64 载荷”表达应用自己的保存格式，仅说明字节往返，不讨论密钥文件权限和线上密钥管理。

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

先纠正 ParsePrivateKey 的接口名称

这个问题可以拆成两个明确边界：私钥对象怎样编码，以及编码怎样被解释。Bytes 负责取出私钥编码副本；Curve.NewPrivateKey 在调用方选择的曲线下检查字节并创建对象。恢复对象并不是对任意文本调用一个统一的“解析私钥”入口。

因此，遇到 ParsePrivateKey 未定义的编译问题，先看自己究竟拿到了哪种格式。如果输入确实来自 Bytes，正确入口是曲线方法；如果来自 PKCS#8 文件，则应进入 crypto/x509 的容器解析路径。两者不能根据名称相似而替换。

这个组织方式适合应用内部明确约定原始编码的场景。它的代价是保存记录的格式和曲线标签需要应用自己维护；仅仅让函数返回了 PrivateKey，不代表数据来源和曲线选择都可信。

保存格式必须同时约定曲线和原始字节

这些字段是本文示例定义的应用协议，不是 Go 标准密钥文件格式。调用方可以采用其他记录方式，但必须让写出和读入对同一套含义达成一致。尤其不要在一处省略 Base64 填充，另一处却用不同的编码器恢复。

Base64 只解决文本表示，不提供加密、真实性或完整性保护。JSON 记录和其中的载荷依然是私钥材料，示例不会打印它们；这里也不把一个序列化函数宣传成完整的保密存储方案。

用 Bytes 与 NewPrivateKey 完成最小往返

下面的完整原创程序在内存里完成生成、序列化、恢复和比较。encoded 是可交给应用保存层的字节内容；为把重点保持在格式往返上，代码没有写入磁盘。实际保存后读回的内容应原样传给 restoreKey，而不是重新生成另一把私钥。

package main

import (
    "crypto/ecdh"
    "crypto/rand"
    "encoding/base64"
    "encoding/json"
    "fmt"
)

type savedKey struct {
    Version   int
    Curve     string
    KeyBase64 string
}

func exportKey(k *ecdh.PrivateKey) ([]byte, error) {
    if k == nil {
        return nil, fmt.Errorf("私钥为空")
    }
    name := ""
    switch k.Curve() {
    case ecdh.P256():
        name = "P-256"
    case ecdh.P384():
        name = "P-384"
    case ecdh.P521():
        name = "P-521"
    case ecdh.X25519():
        name = "X25519"
    default:
        return nil, fmt.Errorf("不支持的曲线")
    }
    // Base64 仅包装字节，不是加密；结果仍是私钥材料。
    rec := savedKey{1, name, base64.StdEncoding.EncodeToString(k.Bytes())}
    return json.Marshal(rec)
}

func restoreKey(data []byte) (*ecdh.PrivateKey, error) {
    var rec savedKey
    if err := json.Unmarshal(data, &rec); err != nil {
        return nil, fmt.Errorf("读取保存记录: %w", err)
    }
    if rec.Version != 1 {
        return nil, fmt.Errorf("不支持的格式版本: %d", rec.Version)
    }
    var curve ecdh.Curve
    switch rec.Curve {
    case "P-256":
        curve = ecdh.P256()
    case "P-384":
        curve = ecdh.P384()
    case "P-521":
        curve = ecdh.P521()
    case "X25519":
        curve = ecdh.X25519()
    default:
        return nil, fmt.Errorf("未知曲线: %q", rec.Curve)
    }
    raw, err := base64.StdEncoding.DecodeString(rec.KeyBase64)
    if err != nil {
        return nil, fmt.Errorf("解码私钥载荷: %w", err)
    }
    // 按记录中声明的曲线解析原始字节，必须处理错误。
    k, err := curve.NewPrivateKey(raw)
    if err != nil {
        return nil, fmt.Errorf("恢复 %s 私钥: %w", rec.Curve, err)
    }
    return k, nil
}

func run() error {
    original, err := ecdh.P256().GenerateKey(rand.Reader)
    if err != nil {
        return fmt.Errorf("生成私钥: %w", err)
    }
    encoded, err := exportKey(original)
    if err != nil {
        return err
    }
    restored, err := restoreKey(encoded)
    if err != nil {
        return err
    }
    // 只输出比较结论，不打印 encoded 或原始私钥。
    fmt.Println("私钥往返一致:", original.Equal(restored))
    fmt.Println("公钥往返一致:", original.PublicKey().Equal(restored.PublicKey()))
    return nil
}

func main() {
    if err := run(); err != nil {
        fmt.Println("往返失败:", err)
    }
}

示例用 P-256 生成密钥，恢复函数则通过明确的曲线名选择接口。每一层分别处理 JSON、版本、曲线、Base64 和私钥编码错误，避免把所有失败都压成一个无法定位的“解析失败”。

往返判断使用 PrivateKey.Equal 与对应公钥的 Equal，不直接比较两个对象的指针地址。按同一编码与曲线恢复的预期，二者应表示相同密钥；本文没有运行程序，也没有声称打印了实际结果。

Bytes 返回编码副本，因此不能把返回切片的修改理解为修改原私钥对象。它仍然是一份额外的私钥材料，调用方应清楚它在程序中被传给了谁。本文不对运行时内存副本的销毁行为作额外保证。

错误曲线与文本编码为什么容易混淆

错误曲线不一定总能靠“解析失败”发现。P-256 与 X25519 的原始私钥都可能呈现相同字节长度，但语义和检查规则不同。能被另一条曲线接受，不能证明它就是原来的那把密钥。

对于 NIST 曲线，NewPrivateKey 会按相应规则检查固定长度整数以及有效范围；X25519 的私钥构造主要检查标量长度。读取端不能只测字节长度就推断曲线，更不能在某条曲线失败后轮流尝试所有曲线，把第一个成功当作正确答案。

另一个常见反例是把 Base64 字符串直接转成 []byte 后传入 NewPrivateKey。那得到的是文本字符的字节，而非原始私钥。正确做法是先 DecodeString，检查解码错误，再把解码后的 raw 交给曲线。

如果 Base64 数据被截断或复制时混入非预期内容，应报告保存记录损坏，而不是自动补字节或用零填充。恢复函数的职责是按协议解释数据，不能通过修补随机输入来保证得到“某个可用私钥”。

原始字节和 PKCS#8 不能混用

PKCS#8 是容器编码路线。与之对应的函数是 x509.MarshalPKCS8PrivateKey 和 x509.ParsePKCS8PrivateKey。它们处理的输入输出，不能直接拿来替代 Bytes 与 NewPrivateKey 之间的原始字节契约。

解析 PKCS#8 返回的具体密钥类型也需要检查。对 NIST 曲线，官方文档指出解析后可能需要通过 ECDSA 私钥的 ECDH 方法转换；不能对返回的任意对象盲目断言为 *ecdh.PrivateKey。本文只指出接口边界，不把容器转换扩写成第二套保存教程。

选择哪条路线应在格式设计时决定。应用内部已固定原始编码和曲线，可以采用本文的记录方案；需要与已有 PKCS#8 生态对接时，则应遵循容器格式。不要把两种编码都称作“私钥字节”而省略格式说明，之后再靠猜测解析。

接入保存层之前的判断清单

• 确认输入来自 Bytes 原始编码还是 PKCS#8 容器。
• 原始编码明确曲线来源，恢复时不轮流猜曲线。
• 文本编码和字节编码分层，Base64 解码失败立即返回。
• 保存记录带格式版本，未知版本或曲线名明确拒绝。
• 使用 Equal 判断往返身份，不打印私钥载荷或比较对象地址。

这个方案把保存记录和曲线解析的责任分开，适合有明确格式契约的应用内部往返。它不承担来源认证、密钥生命周期管理或跨系统格式协商；这些需求存在时，应在相应层独立定义，不能仅靠 Bytes 的返回值解决。

为什么文档里找不到 ParsePrivateKey？

因为 crypto/ecdh 的原始私钥恢复入口叫 Curve.NewPrivateKey。若你需要的其实是容器解析，则看 x509.ParsePKCS8PrivateKey，并检查返回类型。

只保存公钥，能恢复私钥吗？

不能把 PublicKey.Bytes 当作 PrivateKey.Bytes 的替代品。公钥字节应由 NewPublicKey 解释，不能用它完成私钥往返保存。

保存的曲线标签改了，代码还能成功就算正确吗？

不能。标签决定字节的解释方式，解析成功只表示它符合所选接口的输入规则。往返身份必须建立在正确曲线和正确原始字节之上，标签本身也不能被当成真实性证明。

参考：crypto/ecdh 官方私钥与曲线接口、x509 PKCS#8 解析接口、Base64 编码接口。示例保存协议与代码为本文原创。