Go crypto/ecdh.NewPrivateKey 怎么导入现有私钥字节

服务规模变大以后，ECDH 私钥往往不再只由当前进程现场生成：有的来自密钥服务，有的从旧系统迁移，有的以 PKCS#8 保存，还有的只留下固定长度的原始标量字节。我遇到过的典型故障，是把所有“看起来像私钥”的字节都直接传给 crypto/ecdh.NewPrivateKey。结果同一份密钥在一个服务能导入，在另一个服务却报长度或范围错误。

正确做法并不复杂：先确认载荷格式和曲线。如果手里是原始私钥标量，就选择匹配的 ecdh.Curve 后调用 curve.NewPrivateKey(raw)；如果是 PEM、PKCS#8 或 SEC1 容器，则先由 encoding/pem、crypto/x509 解开容器，再转换为 ECDH 私钥。Go 标准库文档：https://pkg.go.dev/crypto/ecdh。

一、先判断手里的字节到底是什么格式

NewPrivateKey 不是一个“万能私钥解析器”。它要求调用方已经知道曲线，并提供该曲线认可的原始私钥编码。十六进制或 Base64 只是文本编码方式，解码后可能得到原始标量，也可能得到一整个 DER 容器；两者不能混用。

可以先按来源判断：如果字节来自 PrivateKey.Bytes()，通常可以用同一曲线的 NewPrivateKey 还原；如果来源是证书工具、OpenSSL 导出文件或密钥管理系统，就要查看它声明的是 PKCS#8、SEC1 还是 raw。PEM 还多一层文本封装，需要先 pem.Decode 才能拿到 DER。

规模化系统里最容易形成瓶颈的做法，是在每个服务中各写一段“先试 P-256，再试 X25519”的猜测逻辑。它会让错误变得不稳定，也掩盖上游元数据丢失。更可靠的输入契约至少要包含 format、curve 和 payload 三项。

二、原始标量字节：选曲线后调用 NewPrivateKey

下面以 P-256 为例。调用前先把十六进制文本解码成原始字节，并在业务边界检查固定长度。最终合法性仍交给 NewPrivateKey：对 NIST 曲线，它会把输入视为固定长度大端整数，检查是否小于曲线阶，并拒绝零私钥。

package keyimport

import (
	"crypto/ecdh"
	"encoding/hex"
	"fmt"
)

func ImportP256(hexKey string) (*ecdh.PrivateKey, error) {
	// 文本只负责运输；解码后必须得到 P-256 的 32 字节原始标量。
	raw, err := hex.DecodeString(hexKey)
	if err != nil {
		return nil, fmt.Errorf("解码私钥: %w", err)
	}
	if len(raw) != 32 {
		return nil, fmt.Errorf("P-256 私钥长度应为 32 字节，实际为 %d", len(raw))
	}

	// 曲线决定字节的解释方式，合法性由标准库完成最终检查。
	key, err := ecdh.P256().NewPrivateKey(raw)
	if err != nil {
		return nil, fmt.Errorf("导入 P-256 私钥: %w", err)
	}
	return key, nil
}

P-384 和 P-521 的原始私钥编码分别使用 48 和 66 字节；X25519 使用 32 字节，且 NewPrivateKey 在这一入口只检查标量长度。即使长度相同，P-256 与 X25519 也不是同一曲线，不能只根据“都是 32 字节”来选择入口。调用方应从可信元数据读取曲线标识。

三、PKCS#8 或 PEM：先解容器，再转换成 ECDH

PKCS#8 DER 中除了私钥材料，还带有算法标识等结构信息。把整段 DER 传给 NewPrivateKey，长度自然不符合原始标量要求。标准库文档明确说明，ECDH 私钥可以通过 x509.ParsePKCS8PrivateKey 解析；对 NIST 曲线，解析结果通常是 *ecdsa.PrivateKey，还需要调用其 ECDH() 方法完成转换。

package keyimport

import (
	"crypto/ecdh"
	"crypto/ecdsa"
	"crypto/x509"
	"encoding/pem"
	"fmt"
)

func ImportPKCS8PEM(data []byte) (*ecdh.PrivateKey, error) {
	// PEM 是文本外壳，Block.Bytes 才是要交给 x509 的 DER。
	block, rest := pem.Decode(data)
	if block == nil || len(rest) != 0 {
		return nil, fmt.Errorf("不是单个完整的 PEM 私钥块")
	}

	parsed, err := x509.ParsePKCS8PrivateKey(block.Bytes)
	if err != nil {
		return nil, fmt.Errorf("解析 PKCS#8 私钥: %w", err)
	}

	switch key := parsed.(type) {
	case *ecdh.PrivateKey:
		return key, nil
	case *ecdsa.PrivateKey:
		// NIST 曲线解析后先得到 ECDSA 私钥，再转换为同曲线 ECDH 私钥。
		return key.ECDH()
	default:
		return nil, fmt.Errorf("PKCS#8 中的私钥类型不支持 ECDH: %T", parsed)
	}
}

如果调用方已经拿到 PKCS#8 DER，就跳过 pem.Decode，直接解析 DER。若文件是 SEC1 EC PRIVATE KEY，则应使用对应的 x509.ParseECPrivateKey，再调用 ECDH()；不要把不同容器格式混进一个模糊的重试链。

四、服务间长期保存时，格式和曲线要一起版本化

当密钥跨服务、跨语言或跨年份保存时，我更倾向于建立一个单一导入适配层，而不是让业务代码直接接触裸字节。输入对象可以显式声明 version、format、curve 和密文载荷；适配层负责解密、解容器、校验曲线并构造 *ecdh.PrivateKey。

这里的关键取舍是：容器格式更适合标准化交换，raw 更紧凑但强依赖外部曲线元数据。无论选择哪一种，都应把私钥放在受控密钥存储中，传输和静态保存均加密，错误信息只描述格式、曲线和长度，不回显载荷。

五、导入完成后还要检查哪些边界

PrivateKey.Bytes() 会返回私钥编码的副本，可用于受控的回环测试：对新生成的测试密钥取 Bytes()，再用同一曲线 NewPrivateKey 导入，并用 Equal 检查对象是否表示同一密钥。这个测试只应使用测试密钥；生产私钥内容不应写入日志、错误、监控标签或测试快照。

真正执行 ECDH 时，本地私钥与远端公钥还必须使用同一曲线。导入成功只能证明私钥编码对所选曲线有效，并不能证明对端公钥、协议版本或密钥用途匹配。把曲线检查放在协议边界，错误会比计算阶段才暴露更容易定位。

相关问题

为什么 32 字节私钥仍然导入失败？

32 字节只说明长度可能符合 P-256 或 X25519，不能证明曲线正确。P-256 还会检查大端整数是否为零或不小于曲线阶；同时确认上游提供的是 raw，而不是截取或误解码后的容器内容。

NewPrivateKey 会复制传入的字节吗？

调用方不应依赖传入切片作为密钥对象的可变存储。导入后仍应尽快清理自己持有的临时缓冲区，并通过标准库对象使用密钥；Bytes() 返回的是编码副本。

能否通过不断尝试不同曲线自动识别？

不建议。某些曲线的原始私钥长度相同，试探可能得到“可导入但语义错误”的结果。让曲线成为可信、可审计的显式元数据，才适合长期维护。

参考：https://pkg.go.dev/crypto/ecdh。其中 Curve.NewPrivateKey、PrivateKey.Bytes、PKCS#8 解析与 NIST 曲线转换说明，是判断导入边界的直接依据。