Go crypto/ecdh PrivateKey.Bytes 如何导出密钥材料：曲线格式、复制语义与敏感数据清理

做 ECDH 密钥交换时，私钥对象不是普通的配置字节。真正容易出错的地方有三个：PrivateKey.Bytes() 返回什么格式、拿到的切片能不能改，以及传入错误长度后应该在哪里发现问题。下面用 Go 的 crypto/ecdh 跑一遍 X25519 与 P-256，把这些边界落到可核对的输出上。

先把 PrivateKey.Bytes 的边界跑出来

crypto/ecdh 把曲线和密钥材料封装在对象里。示例先用固定的 32 字节输入构造 X25519 私钥，再故意修改第一次导出的切片；随后用 P-256 的 31 字节输入验证长度错误，最后完成一次 ECDH。

priv, err := ecdh.X25519().NewPrivateKey(seed)
got := priv.Bytes()
got[0] ^= 0xff
second := priv.Bytes()

_, badErr := ecdh.P256().NewPrivateKey(make([]byte, 31))
peer, _ := ecdh.X25519().GenerateKey(rand.Reader)
shared, ecdhErr := priv.ECDH(peer.PublicKey())

X25519 的长度不是可随意改变的参数

本次运行输出 private_len=32、public_len=32。这里的长度检查应放在输入边界，而不是依赖后面的共享密钥调用来“顺便发现”。如果密钥来自文件、环境变量或协议字段，先检查字节长度，再交给 NewPrivateKey，错误会更接近真正的输入来源。

从官方实现和包文档看，PrivateKey 代表通常应保持秘密的 ECDH 私钥；编码和解析应交给 crypto/ecdh 或 crypto/x509 的对应接口，不要自己截断、补零或把十六进制字符串直接当作密钥。

修改 Bytes 返回值，为什么不会改掉私钥对象

示例把 got[0] 与 0xff 异或，然后再次调用 priv.Bytes()。输出中的 copy_independent=true first_byte=01 表明第二次读取仍是原始首字节。这个行为很重要：调用方可以拿到编码副本做一次性封装，但不能据此推断底层私钥对象已经被清零。

反过来，也不要把“返回副本”理解成“可以安全长期保存”。副本本身仍然是敏感密钥材料；不需要时应尽快释放引用，避免写入日志、错误信息、埋点字段或普通缓存。

把非法长度和 ECDH 成功状态分开验收

P-256 的错误输入输出为 crypto/ecdh: invalid private key，而合法的 X25519 对端交换输出 ecdh_shared_len=32、ecdh_error=。两个结果属于不同验收层次：前者证明输入校验生效，后者证明密钥交换路径完成。

生产代码里建议保留的三道检查

• 输入来自外部时，先限制长度和来源，再调用 NewPrivateKey；不要把错误输入带进更深的协议流程。
• 需要导出时只在边界处调用 Bytes()，使用后避免格式化、打印和写入持久化介质。
• 完成 ECDH 后还要检查返回错误，再把共享结果交给后续 KDF；共享结果不是可直接当业务密码的字符串。

常见问题

PrivateKey.Bytes 返回的是原始私钥吗？

它返回私钥编码的字节副本。副本内容仍然敏感，不能因为对象内部没有直接暴露字段就放进日志。

为什么示例要用 rand.Reader 生成对端密钥？

Go 1.24 的 GenerateKey 需要有效的随机源；生产代码应使用 crypto/rand.Reader，测试若要确定性输入则直接使用受控字节调用 NewPrivateKey。

31 字节能否补零后交给 P-256？

不建议自行补齐。让 NewPrivateKey 按曲线规则验证真实编码，补零可能掩盖上游协议或存储层的长度错误。

ECDH 返回 32 字节就代表可以直接存数据库吗？

不代表。共享结果还需要按协议进入合适的密钥派生流程，并根据用途控制生命周期，不能把长度当作安全性结论。

小结

处理 crypto/ecdh.PrivateKey 时，先让曲线 API 校验输入，再把 Bytes() 看作一次性编码副本，最后分别验收错误输入和合法 ECDH 路径。这样既能解释 32 字节长度，也能避免把敏感材料误当成普通可变切片。