X25519 Encrypt & Decrypt

Free online X25519 Encrypt & Decrypt tool. 100% local processing — your data never leaves your device.

National Standards
Other
Output

Result will be displayed here...

Input → Encrypt

Usage Guide

About X25519 (Curve25519 ECDH)

X25519 is the Diffie-Hellman key exchange function built on Curve25519, standardized in RFC 7748. It is the most widely deployed elliptic-curve key exchange algorithm in the world — used as the default key exchange in TLS 1.3, WireGuard VPN, Signal Protocol, and the Noise Protocol Framework. X25519 provides ~128-bit security with 32-byte keys, is designed to be resistant to side-channel attacks, and was created by Daniel J. Bernstein.

Key Exchange — Not Encryption: X25519 performs key agreement only. It produces a shared secret that both parties can compute independently — it does not encrypt or decrypt any data by itself. You must use the resulting shared secret as a key for a symmetric cipher such as ChaCha20-Poly1305 or AES-256-GCM to achieve confidentiality.

Usage Steps

This tool computes the X25519 Diffie-Hellman shared secret from your private key and your peer's public key:

•
1. Generate Key PairClick 'Generate Key Pair' to create a fresh X25519 key pair. The private key (64 hex characters) is filled into the 'My Private Key' field. Your corresponding public key is stored internally — share it with your peer out-of-band (copy it from the key pair display).
•
2. Exchange Public KeysSend your public key (64 hex characters) to your communication partner. Receive their public key. Paste it into the 'Peer Public Key (Hex)' field. This exchange can happen over any channel — the public key is not secret.
•
3. Compute Shared SecretClick 'Encrypt'. The tool performs DH(your_private_key, peer_public_key) and outputs a 64-character hex shared secret (32 bytes). Your peer performs the same operation in reverse and obtains the identical shared secret.
•
4. Use Shared Secret for EncryptionFeed the shared secret (or a KDF-derived key from it) into a symmetric cipher like AES-256-GCM or ChaCha20-Poly1305. The shared secret itself should not be used directly as a cipher key without key derivation (e.g., HKDF) in production systems.
Browser-Only: All key generation and DH computations run entirely in your browser using the WebCrypto API. No keys are ever transmitted to a server.

Key Format

X25519 keys in this tool use a compact hexadecimal format:

•
Private Key64 hex characters = 32 bytes. A random scalar value. Keep it secret. Example: a3f1e2d4c5b6a7f8e9d0c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2
•
Public Key64 hex characters = 32 bytes. The result of multiplying the base point on Curve25519 by the private key scalar. Safe to share publicly. Example: 5b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8
•
Shared Secret64 hex characters = 32 bytes. Computed as DH(my_private, peer_public) = DH(peer_private, my_public). This equality is the mathematical foundation of Diffie-Hellman key exchange.
•
Key Non-InterchangeabilityX25519 and Ed25519 keys look identical (64 hex chars, 32 bytes) but use different internal representations and are NOT interchangeable. Never use an Ed25519 private key as an X25519 private key or vice versa.

X25519 vs EdDSA (Ed25519)

X25519 and Ed25519 are both based on Curve25519 but serve completely different cryptographic purposes:

•
PurposeX25519: key exchange (Diffie-Hellman). Ed25519: digital signatures (authentication). They cannot substitute for each other.
•
Mathematical FormX25519 uses the Montgomery form of Curve25519 for efficient scalar multiplication. Ed25519 uses the twisted Edwards form. Although they are birationally equivalent curves, the key encodings differ.
•
Key InterchangeabilityKeys are NOT interchangeable despite the same byte length. Using an Ed25519 key pair for X25519 DH is a cryptographic misuse that could compromise security.
•
Combined UseIn practice, protocols like Signal use both together: X25519 for key agreement (establishing the session key) and Ed25519 for authentication (signing the key exchange to prevent MITM attacks).
Related Tools: For digital signatures, use the EdDSA (Ed25519) tool. For symmetric encryption with the shared secret, use ChaCha20-Poly1305 or AES-256-GCM.

FAQ

Q: What is the difference between X25519 and ECDH?

A: X25519 is ECDH — specifically, Elliptic Curve Diffie-Hellman instantiated over Curve25519. The name "X25519" refers to the x-coordinate scalar multiplication function on Curve25519 defined in RFC 7748. Compared to ECDH over NIST curves (P-256, P-384), X25519 is faster, has a simpler and safer implementation (no cofactor issues, no point validation requirements for typical inputs), and was designed from the ground up for resistance to implementation attacks. When people say "ECDH with Curve25519" they mean X25519.

Q: Can X25519 and Ed25519 keys be used interchangeably?

A: No. Although both X25519 and Ed25519 are based on Curve25519, they use different mathematical representations (Montgomery form vs. twisted Edwards form) and different key encodings. An X25519 private key is a raw 32-byte scalar; an Ed25519 private key is a 32-byte seed that is hashed (SHA-512) before use. While there exist conversion formulas between the two key types, using them interchangeably without explicit conversion is cryptographically incorrect and can leak information or produce invalid results. Always generate separate key pairs for each purpose.

Q: How do I use the shared secret to encrypt data?

A: The 32-byte X25519 shared secret should be passed through a Key Derivation Function (KDF) before use as a cipher key. In practice: HKDF-SHA256 is the most common choice (used in TLS 1.3, Signal). Pass the raw shared secret as input key material, include a protocol-specific salt and info string, and derive 32 bytes for AES-256-GCM or ChaCha20-Poly1305. For simple use cases, you can use the shared secret directly as a 32-byte AES-256 key, but HKDF is strongly recommended in production.

Q: Does X25519 provide forward secrecy?

A: Yes — when used with ephemeral key pairs. Forward secrecy (also called Perfect Forward Secrecy, PFS) means that compromising a long-term key does not expose past session keys. In TLS 1.3, both parties generate fresh X25519 key pairs for each handshake (ephemeral DH). Even if an attacker later obtains a server's long-term private key, they cannot decrypt previously recorded traffic because the ephemeral X25519 keys were discarded after the handshake. Static (reused) X25519 keys do NOT provide forward secrecy.

Q: Is X25519 resistant to quantum attacks?

A: No — not against a sufficiently large quantum computer. A quantum computer running Shor's algorithm could break X25519 by solving the elliptic curve discrete logarithm problem in polynomial time. This applies equally to all elliptic curve and finite-field Diffie-Hellman schemes. However, the required quantum computer (thousands of error-corrected logical qubits) does not yet exist. For post-quantum key exchange, NIST has standardized ML-KEM (formerly CRYSTALS-Kyber). Some protocols (like TLS 1.3 in Chrome and Firefox) already deploy hybrid X25519+ML-KEM key exchange to achieve both classical and post-quantum security simultaneously.

Use Cases

Recommended: TLS 1.3 Key Exchange

X25519 is the preferred key exchange algorithm in TLS 1.3 (RFC 8446) and is supported by all major browsers and servers. In TLS 1.3, the client and server each generate ephemeral X25519 key pairs, exchange public keys in the ClientHello/ServerHello, and derive the handshake keys using HKDF. This provides forward secrecy and completes in a single round-trip. X25519 replaced RSA key exchange and older ECDH variants in TLS 1.3's mandatory cipher suite.

Recommended Configuration:
  • ✅ Enable TLS 1.3 on all servers — X25519 is included automatically
  • ✅ X25519 provides forward secrecy in every TLS 1.3 handshake
  • ✅ Supported natively in OpenSSL, BoringSSL, NSS, and all major TLS libraries
  • ❌ Don't use TLS 1.2 RSA key exchange — it lacks forward secrecy
Recommended: WireGuard VPN

WireGuard uses X25519 as its sole key exchange mechanism. Each WireGuard peer has a static X25519 key pair (for authentication) and generates ephemeral X25519 key pairs for each handshake (for forward secrecy). The protocol also uses X25519 for preshared key mixing and employs the Noise Protocol Framework. WireGuard's minimalist design — one key exchange algorithm, one symmetric cipher (ChaCha20-Poly1305), one hash (BLAKE2s) — makes it auditable and fast.

Recommended Configuration:
  • ✅ X25519 is the only key exchange in WireGuard — nothing to configure
  • ✅ Generate static key pairs with: wg genkey | tee private.key | wg pubkey > public.key
  • ✅ WireGuard provides automatic forward secrecy via ephemeral key pairs
  • 💡 WireGuard combines X25519 (key exchange) + ChaCha20-Poly1305 (encryption) + BLAKE2s (hashing)
Recommended: End-to-End Encrypted Messaging (Signal, WhatsApp)

The Signal Protocol (used by Signal, WhatsApp, and many others) uses X25519 extensively in its Double Ratchet Algorithm and X3DH (Extended Triple Diffie-Hellman) key agreement. X3DH uses multiple X25519 DH operations to establish initial shared keys between parties who may be offline. The Double Ratchet then continuously derives new keys from the X25519 ratchet, providing both forward secrecy and break-in recovery. This is considered the gold standard for secure messaging.

Recommended Configuration:
  • ✅ X25519 is the foundation of Signal Protocol key agreement
  • ✅ X3DH enables asynchronous key establishment (one party can be offline)
  • ✅ Double Ratchet + X25519 provides forward secrecy and post-compromise security
  • 💡 WhatsApp, Wire, Facebook Messenger secret chats all use Signal Protocol
Recommended: Hybrid Encryption (Key Encapsulation)

Hybrid encryption uses X25519 to establish a shared secret, then encrypts the actual data with a symmetric cipher. This pattern (called ECIES or HPKE — Hybrid Public Key Encryption, RFC 9180) allows anyone with the recipient's X25519 public key to send encrypted data without pre-shared secrets. The sender generates an ephemeral X25519 key pair, computes a shared secret with the recipient's public key, derives a symmetric key via HKDF, encrypts data with ChaCha20-Poly1305, and sends the ephemeral public key alongside the ciphertext.

Recommended Configuration:
  • ✅ Use HPKE (RFC 9180) for standardized hybrid encryption with X25519
  • ✅ Ephemeral sender key pair ensures forward secrecy for each message
  • ✅ Combine: X25519 (key exchange) + HKDF (key derivation) + AES-256-GCM (encryption)
  • 💡 This pattern is used in age (file encryption tool) and Tink library
Not Recommended: Using X25519 Alone for Confidentiality

X25519 only produces a shared secret — it does not encrypt any data. The shared secret itself is not ciphertext; any party who performs the same DH computation (with the correct keys) obtains it. Without a symmetric cipher applied on top, your data remains in plaintext. This is a fundamental misuse of the algorithm. Always combine X25519 with AES-256-GCM or ChaCha20-Poly1305 to actually protect data.

Recommended Configuration:
  • ❌ Don't treat the X25519 shared secret as ciphertext — it is a key, not encrypted data
  • ❌ Don't skip key derivation — run the shared secret through HKDF before using as a cipher key
  • ✅ X25519 + HKDF + AES-256-GCM is the correct hybrid encryption pattern
  • 💡 X25519 solves the key distribution problem; a symmetric cipher solves data confidentiality

Best Practice Summary

  • X25519 is a key exchange algorithm — it produces a shared secret, not ciphertext. Always pair it with AES-256-GCM or ChaCha20-Poly1305 to encrypt actual data.
  • Run the X25519 shared secret through HKDF-SHA256 before using it as a symmetric cipher key in production systems.
  • Use ephemeral X25519 key pairs (generate a fresh pair per session) to achieve forward secrecy.
  • Do not use X25519 keys as Ed25519 signing keys or vice versa — they use different internal representations even though both are 32 bytes.
  • X25519 is the standard for TLS 1.3, WireGuard, and Signal Protocol — prefer it over older ECDH-with-NIST-curves for new implementations.

Discussion & Feedback

0 comments
Me