X25519 加密解密

免费在线 X25519 加密解密 工具。100% 本地计算，数据不离开您的设备，隐私安全有保障。

National Standards
Other
输出

结果将显示在这里...

输入 → 加密

使用指南

关于 X25519（Curve25519 ECDH）

X25519 是基于 Curve25519 的 Diffie-Hellman 密钥交换函数，由 RFC 7748 标准化。它是目前全球部署最广泛的椭圆曲线密钥交换算法——作为 TLS 1.3、WireGuard VPN、Signal 协议和 Noise 协议框架的默认密钥交换方案。X25519 提供约 128 位安全强度，密钥仅 32 字节，并由 Daniel J. Bernstein 设计以抵抗侧信道攻击。

密钥交换——不是加密：X25519 仅执行密钥协商。它产生双方可独立计算的共享密钥——本身不加密或解密任何数据。您必须将共享密钥用于对称加密算法（如 ChaCha20-Poly1305 或 AES-256-GCM）才能实现保密性。

使用步骤

本工具通过您的私钥和对方的公钥计算 X25519 Diffie-Hellman 共享密钥：

•
1. 生成密钥对点击"生成密钥对"创建新的 X25519 密钥对。私钥（64 个十六进制字符）自动填入"我的私钥"字段。对应的公钥存储在工具内部——请将其复制并通过其他渠道分享给您的通信伙伴。
•
2. 交换公钥将您的公钥（64 个十六进制字符）发送给通信伙伴，并接收对方的公钥，粘贴到"对方公钥（十六进制）"字段。这一交换可通过任何渠道进行，公钥不是秘密。
•
3. 计算共享密钥点击"加密"。工具执行 DH（您的私钥，对方公钥）并输出 64 字符十六进制共享密钥（32 字节）。您的伙伴进行相同操作（方向相反）可得到完全相同的共享密钥。
•
4. 用共享密钥加密数据将共享密钥（或经 KDF 派生的密钥）输入对称加密算法，如 AES-256-GCM 或 ChaCha20-Poly1305。在生产系统中，建议先通过 HKDF 派生密钥，而不直接将共享密钥作为加密密钥使用。
仅在浏览器中运行：所有密钥生成和 DH 计算均通过 WebCrypto API 在您的浏览器中完成。密钥不会传输到服务器。

密钥格式

本工具中的 X25519 密钥使用紧凑的十六进制格式：

•
私钥64 个十六进制字符 = 32 字节。一个随机标量值。必须保密。示例：a3f1e2d4c5b6a7f8e9d0c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2
•
公钥64 个十六进制字符 = 32 字节。Curve25519 基点乘以私钥标量的结果。可公开分享。示例：5b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8
•
共享密钥64 个十六进制字符 = 32 字节。由 DH（我的私钥，对方公钥）= DH（对方私钥，我的公钥）计算得到。这一等式是 Diffie-Hellman 密钥交换的数学基础。
•
密钥不可互换X25519 和 Ed25519 密钥外观相同（64 个十六进制字符，32 字节），但内部表示不同，不可互换。切勿将 Ed25519 私钥用作 X25519 私钥，反之亦然。

X25519 与 EdDSA（Ed25519）对比

X25519 和 Ed25519 都基于 Curve25519，但用途截然不同：

•
用途X25519：密钥交换（Diffie-Hellman）。Ed25519：数字签名（认证）。两者不能相互替代。
•
数学形式X25519 使用 Curve25519 的蒙哥马利形式进行高效标量乘法；Ed25519 使用扭曲爱德华兹形式。虽然两者双有理等价，但密钥编码不同。
•
密钥不可互换尽管字节长度相同，密钥不可互换。将 Ed25519 密钥对用于 X25519 DH 是密码学滥用，可能危及安全性。
•
组合使用实际中，Signal 等协议同时使用两者：X25519 用于密钥协商（建立会话密钥），Ed25519 用于认证（对密钥交换签名以防止中间人攻击）。
相关工具：数字签名请使用 EdDSA（Ed25519） 工具。用共享密钥进行对称加密请使用 ChaCha20-Poly1305 或 AES-256-GCM。

常见问题

Q: X25519 和 ECDH 有什么区别？

A: X25519 就是 ECDH——具体而言是在 Curve25519 上实现的椭圆曲线 Diffie-Hellman，由 RFC 7748 定义。与基于 NIST 曲线（P-256、P-384）的 ECDH 相比，X25519 速度更快，实现更简单安全（无辅因子问题，一般输入无需点验证），并从设计之初就注重抵抗实现层面的攻击。当人们说"使用 Curve25519 的 ECDH"时，指的就是 X25519。

Q: X25519 和 Ed25519 密钥可以互换使用吗？

A: 不能。尽管 X25519 和 Ed25519 都基于 Curve25519，但它们使用不同的数学表示（蒙哥马利形式 vs. 扭曲爱德华兹形式）和不同的密钥编码。X25519 私钥是原始 32 字节标量；Ed25519 私钥是 32 字节种子，使用前需经过 SHA-512 哈希处理。虽然存在两种密钥类型之间的转换公式，但在没有明确转换的情况下互换使用在密码学上是错误的，可能泄漏信息或产生无效结果。请始终为不同用途单独生成密钥对。

Q: 如何用共享密钥加密数据？

A: 32 字节的 X25519 共享密钥在用作加密密钥之前，应通过密钥派生函数（KDF）处理。实践中，HKDF-SHA256 是最常见的选择（TLS 1.3 和 Signal 均使用此方案）。将原始共享密钥作为输入密钥材料，加入协议特定的盐值和信息字符串，派生 32 字节用于 AES-256-GCM 或 ChaCha20-Poly1305。对于简单场景可直接将共享密钥用作 AES-256 的 32 字节密钥，但生产环境中强烈建议使用 HKDF。

Q: X25519 提供前向保密吗？

A: 是的——在使用临时密钥对时。前向保密（也称完美前向保密，PFS）意味着即使长期密钥被泄露，过去的会话密钥也不会暴露。在 TLS 1.3 中，双方在每次握手时生成新的 X25519 密钥对（临时 DH）。即使攻击者日后获得服务器的长期私钥，也无法解密之前录制的流量，因为临时 X25519 密钥在握手结束后即被丢弃。使用静态（复用的）X25519 密钥不提供前向保密。

Q: X25519 是否抗量子攻击？

A: 不——面对足够强大的量子计算机时不抗量子攻击。运行 Shor 算法的量子计算机可通过在多项式时间内求解椭圆曲线离散对数问题来破解 X25519，所有椭圆曲线和有限域 Diffie-Hellman 方案均面临同样威胁。然而，所需的量子计算机（数千个纠错逻辑量子比特）目前尚不存在。对于后量子密钥交换，NIST 已标准化 ML-KEM（原名 CRYSTALS-Kyber）。Chrome 和 Firefox 中的 TLS 1.3 已部署 X25519+ML-KEM 混合密钥交换，同时实现经典和后量子安全性。

使用场景

推荐：TLS 1.3 密钥协商

X25519 是 TLS 1.3（RFC 8446）中首选的密钥交换算法，所有主流浏览器和服务器均支持。在 TLS 1.3 握手中，客户端和服务器各自生成临时 X25519 密钥对，在 ClientHello/ServerHello 中交换公钥，然后使用 HKDF 派生握手密钥。这在单次往返中完成，并提供前向保密。X25519 在 TLS 1.3 的强制密码套件中取代了 RSA 密钥交换和旧版 ECDH 变体。

推荐配置：
  • ✅ 在所有服务器上启用 TLS 1.3——X25519 自动包含在内
  • ✅ X25519 在每次 TLS 1.3 握手中都提供前向保密
  • ✅ OpenSSL、BoringSSL、NSS 及所有主流 TLS 库均原生支持
  • ❌ 不要使用 TLS 1.2 RSA 密钥交换——它缺乏前向保密
推荐：WireGuard VPN

WireGuard 使用 X25519 作为唯一的密钥交换机制。每个 WireGuard 节点拥有静态 X25519 密钥对（用于认证），并在每次握手时生成临时 X25519 密钥对（用于前向保密）。协议还将 X25519 用于预共享密钥混合，并采用 Noise 协议框架。WireGuard 极简的设计——单一密钥交换算法、单一对称加密（ChaCha20-Poly1305）、单一哈希（BLAKE2s）——使其易于审计且性能出色。

推荐配置：
  • ✅ X25519 是 WireGuard 唯一的密钥交换方式，无需配置
  • ✅ 使用命令生成静态密钥对：wg genkey | tee private.key | wg pubkey > public.key
  • ✅ WireGuard 通过临时密钥对自动提供前向保密
  • 💡 WireGuard 组合：X25519（密钥交换）+ ChaCha20-Poly1305（加密）+ BLAKE2s（哈希）
推荐：端对端加密通讯（Signal、WhatsApp）

Signal 协议（被 Signal、WhatsApp 等广泛采用）在其双棘轮算法和 X3DH（扩展三重 Diffie-Hellman）密钥协商中大量使用 X25519。X3DH 通过多次 X25519 DH 操作在可能离线的双方之间建立初始共享密钥。双棘轮随后从 X25519 棘轮持续派生新密钥，同时提供前向保密和入侵后恢复能力。这被认为是安全通讯的黄金标准。

推荐配置：
  • ✅ X25519 是 Signal 协议密钥协商的基础
  • ✅ X3DH 支持异步密钥建立（一方可以离线）
  • ✅ 双棘轮 + X25519 同时提供前向保密和事后安全
  • 💡 WhatsApp、Wire、Facebook Messenger 私密对话均使用 Signal 协议
推荐：混合加密（密钥封装）

混合加密使用 X25519 建立共享密钥，然后用对称加密算法加密实际数据。这种模式（称为 ECIES 或 HPKE——混合公钥加密，RFC 9180）允许任何持有接收方 X25519 公钥的人在没有预共享密钥的情况下发送加密数据。发送方生成临时 X25519 密钥对，与接收方公钥计算共享密钥，通过 HKDF 派生对称密钥，用 ChaCha20-Poly1305 加密数据，并将临时公钥与密文一起发送。

推荐配置：
  • ✅ 使用 HPKE（RFC 9180）进行基于 X25519 的标准化混合加密
  • ✅ 临时发送方密钥对确保每条消息的前向保密
  • ✅ 组合：X25519（密钥交换）+ HKDF（密钥派生）+ AES-256-GCM（加密）
  • 💡 age（文件加密工具）和 Tink 库采用此模式
不推荐：单独使用 X25519 保证保密性

X25519 仅产生共享密钥——它不加密任何数据。共享密钥本身不是密文；任何执行相同 DH 计算（持有正确密钥）的人都能得到它。不在其上应用对称加密，数据将保持明文状态。这是对算法的根本性误用。请始终将 X25519 与 AES-256-GCM 或 ChaCha20-Poly1305 结合使用来真正保护数据。

推荐配置：
  • ❌ 不要将 X25519 共享密钥视为密文——它是密钥，不是加密数据
  • ❌ 不要跳过密钥派生——将共享密钥通过 HKDF 处理后再用作加密密钥
  • ✅ X25519 + HKDF + AES-256-GCM 是正确的混合加密模式
  • 💡 X25519 解决密钥分发问题；对称加密解决数据保密问题

最佳实践总结

  • X25519 是密钥交换算法——产生共享密钥，而非密文。必须与 AES-256-GCM 或 ChaCha20-Poly1305 配合使用才能加密实际数据。
  • 在生产系统中，将 X25519 共享密钥通过 HKDF-SHA256 派生后再用作对称加密密钥。
  • 使用临时 X25519 密钥对（每次会话生成新密钥对）以实现前向保密。
  • 不要将 X25519 密钥用作 Ed25519 签名密钥，反之亦然——尽管都是 32 字节，但内部表示不同。
  • X25519 是 TLS 1.3、WireGuard 和 Signal 协议的标准——新项目优先选用，而非基于 NIST 曲线的旧版 ECDH。

讨论与反馈

0 条评论
我