Go crypto/ecdh X25519 公钥为什么固定为 32 字节

接入 ECDH 协议时，如果对端约定的是 X25519，公钥字段通常就应该是固定的 32 字节。这个长度不是 Go 临时规定的，也不是把一条椭圆曲线公钥“截短”后的结果：X25519 使用的是 Curve25519 上的 Montgomery u 坐标，标准编码直接保存一个 32 字节的坐标值。

因此，crypto/ecdh 的正确做法是先根据协议确定曲线，再把对应编码交给该曲线的 NewPublicKey。不要把 P-256 的未压缩点、PEM 文本或带曲线标识的 DER 数据直接当成 X25519 的 32 字节输入。

官方文档：https://pkg.go.dev/crypto/ecdh

先回答：为什么正好是 32 字节

X25519 的公钥是一个有限域元素的标准字节编码，长度为 32 字节，也就是 256 bit。这里的“公钥”更接近一个经过约定编码的 u 坐标，而不是 NIST 曲线常见的 0x04 + X + Y 点格式。

Go 文档对 ecdh.X25519().NewPublicKey 的约束也很直接：X25519 只检查传入的 u 坐标长度；长度不对时无法构造对应的 PublicKey。这就是为什么协议层必须保留曲线字段或上下文，不能只传一段“看起来像公钥”的字节。

用 NewPublicKey 接收对端的 32 字节公钥

实际接收网络字段时，先复制或切片出公钥字段，再调用 X25519 曲线的 NewPublicKey。示例只演示导入边界，不生成真实密钥，也不把示例数组当成可用的生产密钥。

package main

import (
    "crypto/ecdh"
    "fmt"
)

func parseX25519PublicKey(encoded []byte) (*ecdh.PublicKey, error) {
    // X25519 的公钥编码固定为 32 字节，先在协议边界给出清晰错误。
    if len(encoded) != 32 {
        return nil, fmt.Errorf("X25519 public key length = %d, want 32", len(encoded))
    }

    // NewPublicKey 负责按 X25519 曲线解释 u 坐标并构造不透明公钥对象。
    return ecdh.X25519().NewPublicKey(encoded)
}

func main() {
    wireKey := make([]byte, 32) // 示例占位数据，不代表真实公钥。
    key, err := parseX25519PublicKey(wireKey)
    if err != nil {
        // 解析失败时不要继续进入 ECDH，避免把错误字节当成密钥使用。
        fmt.Println("invalid peer key:", err)
        return
    }
    fmt.Println("peer key bytes:", len(key.Bytes()))
}

这里的长度判断属于协议层的快速失败；即使不写这层判断，NewPublicKey 仍然会检查 X25519 的输入长度。保留显式判断的好处是能把“字段截断”“曲线选错”和“编码损坏”更早地区分出来。

公钥导出和导入为什么能互相对应

PublicKey.Bytes() 返回的是当前公钥编码的一份副本。对同一条 X25519 曲线来说，导出的结果可以作为另一端 NewPublicKey 的输入；但这只说明字节格式对应，并不意味着任何 32 字节数据都能完成有效的密钥交换。

完成 ECDH 时，私钥和对端公钥必须属于同一条曲线。一个常见的工程边界是：协议消息中除了公钥字节，还要能确定算法或曲线，例如把曲线枚举放在字段头里；解析端根据枚举选择 ecdh.X25519()，而不是根据长度猜测曲线。

func exchangeX25519(local *ecdh.PrivateKey, peerBytes []byte) ([]byte, error) {
    // 先按本协议约定的 X25519 格式导入对端公钥。
    peer, err := ecdh.X25519().NewPublicKey(peerBytes)
    if err != nil {
        return nil, fmt.Errorf("parse peer X25519 key: %w", err)
    }

    // ECDH 只接受同曲线的密钥；返回值是共享秘密的原始字节。
    secret, err := local.ECDH(peer)
    if err != nil {
        return nil, fmt.Errorf("compute X25519 shared secret: %w", err)
    }
    return secret, nil
}

共享秘密通常还要进入协议规定的 KDF 或密钥派生步骤，不能直接当作长期对称密钥保存。本文关注的是公钥字节边界，派生算法应由具体协议另行定义。

不要把 X25519 和 P-256 的公钥字节混用

X25519 和 P-256 都能用于 ECDH，但公钥编码不同。X25519 的公开值是固定 32 字节；P-256 的 SEC 1 未压缩点通常由一个前缀字节 0x04 加上两个固定宽度坐标组成，因此常见长度是 65 字节。

这也是“长度校验通过但仍然失败”的典型来源：一段 32 字节数据可能被错误地送到 P-256，或者把 65 字节的 P-256 点送到 X25519。正确的解析顺序应当是先读取曲线标识，再选择曲线，再执行该曲线自己的公钥解析。

工程接入时的五个检查点

1. 先定曲线：协议字段或握手上下文明确写出 X25519、P-256 等算法标识。
2. 再定编码：文档写清楚是裸公钥字节、DER、PEM，还是带自定义头部的二进制字段。
3. 边界校验：对 X25519 预期 32 字节，对 P-256 按所选 SEC 1 编码规则处理，不根据模糊经验猜长度。
4. 错误分层：长度错误、曲线不匹配和 ECDH 计算错误分别记录上下文，避免只返回一个“密钥无效”。
5. 秘密派生：ECDH 返回的共享秘密交给约定的 KDF，不在日志、错误信息或持久化字段中输出。

常见问题

32 字节的 X25519 公钥可以直接 Base64 解码后使用吗？

可以，但前提是 Base64 解码后得到的正是协议约定的裸 X25519 公钥字节；调用 NewPublicKey 前仍要处理解码失败和长度不为 32 的情况。

为什么不能只根据公钥长度判断算法？

长度只能作为局部格式检查，不能承担算法协商。协议扩展、封装方式或未来新增曲线都可能让“猜算法”变成兼容性和安全边界问题。

NewPublicKey 成功就代表 ECDH 一定成功吗？

不代表。X25519 的公钥导入和实际 ECDH 计算是两个阶段；计算时还会受到私钥曲线是否匹配以及对端公钥是否导致无效共享结果等因素影响。

记住一句话：X25519 的 32 字节是它的公钥编码规则，不是所有椭圆曲线公钥的通用长度。先确认曲线和封装，再让对应的 NewPublicKey 解析。