Go crypto/ecdh PrivateKey.ECDH 怎样生成共享密钥

Go 的 crypto/ecdh 中，PrivateKey.ECDH 的调用方式可以先记成一句话：用本端私钥，配合对端公钥，计算双方都能得到的共享密钥。两把密钥必须来自同一条曲线；拿到共享密钥后，还应交给应用层的 KDF 或 AEAD 处理，不要把它直接当作业务密钥文本或密码使用。

PrivateKey.ECDH 的输入到底怎么配对

最容易写反的是第二个参数。Alice 计算时拿 Alice 的私钥和 Bob 的公钥；Bob 计算时拿 Bob 的私钥和 Alice 的公钥。双方不是把自己的私钥传给对方，而是只交换公钥。Go 官方文档还要求两把密钥使用同一条曲线，这个约束应在进入 ECDH 前就明确。

用 P256 让两端得到同一个共享密钥

下面的例子用同一条 P-256 曲线生成两端密钥，并分别计算共享密钥。示例重点是参数方向和错误处理；生产代码还要把私钥放在受控的密钥存储中，避免日志、错误文本或普通业务字段泄露。

package main

import (
    "crypto/ecdh"
    "crypto/subtle"
    "fmt"
)

func main() {
    curve := ecdh.P256()

    // 两端各自生成私钥；真实服务应使用受控密钥生命周期。
    alice, err := curve.GenerateKey(nil)
    if err != nil {
        panic(err)
    }
    bob, err := curve.GenerateKey(nil)
    if err != nil {
        panic(err)
    }

    // 每一端都使用“自己的私钥 + 对方的公钥”。
    aliceSecret, err := alice.ECDH(bob.PublicKey())
    if err != nil {
        panic(err)
    }
    bobSecret, err := bob.ECDH(alice.PublicKey())
    if err != nil {
        panic(err)
    }

    // 这里只比较长度和内容是否相同，不打印共享密钥本身。
    same := len(aliceSecret) == len(bobSecret) &&
        subtle.ConstantTimeCompare(aliceSecret, bobSecret) == 1
    fmt.Println("共享密钥一致：", same)
}

这里的 aliceSecret 和 bobSecret 应该相同，但不要把这种相同关系理解成“公钥可以还原私钥”。公钥交换只提供 ECDH 所需的公开输入，私钥仍由各端保管。

曲线不一致和 X25519 全零结果怎么处理

如果本端私钥来自 P-256，而对端公钥来自 P-384，调用会失败，不能通过强制类型转换绕过。协议层通常应在握手阶段固定曲线或协商后再创建对应密钥对象。X25519 还有一个特殊边界：如果计算结果是全零值，Go 会返回错误，这类结果不能继续送入后续加密步骤。

共享密钥不要直接当成应用层密钥

ECDH 返回的是共享秘密字节。实际协议通常还要经过 KDF，加入双方身份、协议版本、方向或会话上下文，派生出用途明确的 AEAD 密钥、Nonce 材料或其他子密钥。这样可以避免同一份原始共享秘密被多个用途重复使用，也方便在协议升级时隔离不同上下文。

• 只在握手双方需要时保留原始共享秘密，避免写入日志和持久化业务表。
• 不要用字符串格式化、十六进制展示值替代真正的密钥派生。
• 按协议选择标准 KDF 和 AEAD；本文只说明 ECDH 的输入输出边界，不替你决定完整密码协议。

常见问题

为什么不能调用 alice.ECDH(alice.PublicKey())？

这计算的是同一把私钥与自己的公钥组合，不是双方共享密钥协议中的对端输入。正常握手应使用对端公钥。

PrivateKey.ECDH 会返回固定长度的结果吗？

长度取决于使用的 Curve 和实现规则。NIST 曲线返回按规范编码的 x 坐标，X25519 使用其对应的 ECDH 规则，代码不要写死跨曲线的长度假设。

拿到共享密钥后可以直接做 AES 密钥吗？

不建议直接使用。应按协议进入 KDF，绑定上下文并派生用途明确的密钥材料，再交给 AEAD 等对称加密组件。