首页/安全/加密与证书速查/X25519 密钥交换
加密算法基础95 条

X25519 密钥交换

RFC 7748 定义的 ECDH 变体:Curve25519 上的密钥协商,公钥/私钥均为 32 字节,实现简单、性能好,是 TLS 1.3 与 WireGuard 的常用组。

加密与证书速查安全更新于 2026-10-13

X25519 是什么

X25519 是 RFC 7748 定义的 ECDH 变体:在 Curve25519 上做密钥协商,公钥与私钥均为 32 字节,共享秘密同样 32 字节。它实现简单、速度快、对输入校验有明确要求,是 TLS 1.3 的默认优先密钥交换组,也是 WireGuard 与大量现代协议的基础构件。

基本信息

标准RFC 7748
曲线Curve25519(Montgomery 形式)
密钥长度私钥 32 字节、公钥 32 字节
安全强度约 128 位
输出32 字节共享秘密,需再经 KDF 派生密钥
典型用途TLS 1.3 默认组、SSH 密钥交换、WireGuard
配对算法签名用 Ed25519,两者用途必须分开

典型使用场景

  • TLS 1.3 握手:X25519 是常见客户端的首选 key_share 组,能避免额外往返
  • SSH 会话密钥协商:现代 SSH 客户端默认优先使用 curve25519-sha256
  • WireGuard 与隧道协议:用 X25519 协商静态与临时密钥
  • 端到端加密协议:作为前向保密的基础密钥交换方式
  • 临时密钥优先:无 AES 硬件加速与弱网环境下,X25519 的开销更低

生成与观察

生成与观察
# 生成 X25519 密钥对(OpenSSL 1.1.1 起支持)
openssl genpkey -algorithm X25519 -out x.key
openssl pkey -in x.key -pubout -out x.pub
# 查看密钥长度(32 字节)与算法标识
openssl pkey -in x.key -text -noout | head -6
# 观察 TLS 握手实际选用的密钥交换组
openssl s_client -connect example.com:443 -tls1_3 -msg </dev/null 2>&1 | grep -i -m3 'key_share\|group'
# SSH 侧确认协商到的密钥交换算法
ssh -vv example.com 2>&1 | grep -i 'kex' | head -3

与相邻构件对照

构件用途可互换性
X25519密钥协商(ECDH)只能协商,不能签名
Ed25519数字签名只能签名,不能协商
ECDH(P-256)密钥协商与 X25519 不可混用,参数与曲线不同
ECDHE临时密钥交换基于 ECDH,强调每次会话新建密钥
HKDF密钥派生协商出的秘密必须经 KDF 后才能当密钥用
X25519 协商出的 32 字节共享秘密不能直接当密钥使用:它是曲线点坐标,需要经 HKDF 等 KDF 派生出方向与用途分离的密钥。直接用共享秘密当会话密钥是常见误用,会让不同用途的密钥复用同一材料。
X25519 公钥存在小阶点等边界输入,实现需要做输入校验或按标准处理(成熟库已处理)。自研实现若跳过校验,攻击者可用特殊公钥迫使共享秘密变成可预测值,从而绕过密钥协商的安全假设。

易错点

  • 把 X25519 与 Ed25519 混用:前者只做密钥协商,后者只做签名,用途互换会直接失败或破坏安全假设
  • 把共享秘密直接当密钥:缺少 KDF 派生这一步,会导致密钥用途混淆与熵分布不均
  • 自研实现省略公钥校验:特殊公钥可诱导出可预测的共享秘密,成熟库与硬件实现都已内置校验
  • 在只支持 P-256 的老客户端上强推 X25519:客户端无法提供对应 key_share 时会触发 HelloRetryRequest,增加一次往返甚至握手失败
  • 忽略随机数质量:临时私钥必须由密码学安全随机源生成,否则前向保密的实际强度会下降

数据来源与参考

  • RFC 7748(Curve25519 与 Curve448)
  • RFC 8446(TLS 1.3 密钥交换组)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌