X25519 Verschlüsseln

Kostenloses Online-X25519-Verschlüsseln-Tool. 100% lokale Verarbeitung – Ihre Daten verlassen Ihr Gerät nie.

National Standards
Other
Ausgabe

Ergebnis wird hier angezeigt...

Eingabe → Verschlüsseln

Usage Guide

Über X25519 (Curve25519 ECDH)

X25519 ist die Diffie-Hellman-Schlüsselaustauschfunktion auf Basis von Curve25519, standardisiert in RFC 7748. Es ist der weltweit am häufigsten eingesetzte elliptische-Kurven-Schlüsselaustausch-Algorithmus — als Standard-Schlüsselaustausch in TLS 1.3, WireGuard VPN, Signal Protocol und dem Noise Protocol Framework verwendet. X25519 bietet ~128-Bit-Sicherheit mit 32-Byte-Schlüsseln und wurde von Daniel J. Bernstein mit Widerstand gegen Seitenkanalangriffe konzipiert.

Schlüsselaustausch — keine Verschlüsselung: X25519 führt ausschließlich Schlüsselvereinbarung durch. Es erzeugt ein gemeinsames Geheimnis, das beide Parteien unabhängig berechnen können — es verschlüsselt oder entschlüsselt keine Daten. Das resultierende gemeinsame Geheimnis muss als Schlüssel für eine symmetrische Verschlüsselung wie ChaCha20-Poly1305 oder AES-256-GCM verwendet werden, um Vertraulichkeit zu erreichen.

Verwendungsschritte

Dieses Tool berechnet das X25519 Diffie-Hellman gemeinsame Geheimnis aus Ihrem privaten Schlüssel und dem öffentlichen Schlüssel Ihres Kommunikationspartners:

•
1. Schlüsselpaar generierenKlicken Sie auf 'Schlüsselpaar generieren', um ein neues X25519-Schlüsselpaar zu erstellen. Der private Schlüssel (64 Hex-Zeichen) wird in das Feld 'Mein privater Schlüssel' eingetragen. Der entsprechende öffentliche Schlüssel wird intern gespeichert — kopieren Sie ihn und teilen Sie ihn über einen anderen Kanal mit Ihrem Partner.
•
2. Öffentliche Schlüssel austauschenSenden Sie Ihren öffentlichen Schlüssel (64 Hex-Zeichen) an Ihren Kommunikationspartner. Empfangen Sie dessen öffentlichen Schlüssel und fügen Sie ihn in das Feld 'Öffentlicher Schlüssel des Partners (Hex)' ein. Dieser Austausch kann über beliebige Kanäle erfolgen — der öffentliche Schlüssel ist kein Geheimnis.
•
3. Gemeinsames Geheimnis berechnenKlicken Sie auf 'Verschlüsseln'. Das Tool führt DH(Ihr_privater_Schlüssel, Partner_öffentlicher_Schlüssel) aus und gibt ein 64-Zeichen-Hex-Geheimnis (32 Bytes) aus. Ihr Partner führt die gleiche Operation umgekehrt durch und erhält dasselbe gemeinsame Geheimnis.
•
4. Gemeinsames Geheimnis für Verschlüsselung nutzenVerwenden Sie das gemeinsame Geheimnis (oder einen davon abgeleiteten KDF-Schlüssel) mit einer symmetrischen Verschlüsselung wie AES-256-GCM oder ChaCha20-Poly1305. In Produktionssystemen sollte das gemeinsame Geheimnis nicht direkt als Chiffrierschlüssel verwendet werden — leiten Sie es zuvor mit HKDF ab.
Nur im Browser: Alle Schlüsselgenerierungs- und DH-Berechnungen laufen vollständig in Ihrem Browser über die WebCrypto API. Keine Schlüssel werden jemals an einen Server übertragen.

Schlüsselformat

X25519-Schlüssel in diesem Tool verwenden ein kompaktes Hexadezimalformat:

•
Privater Schlüssel64 Hex-Zeichen = 32 Bytes. Ein zufälliger Skalarwert. Geheim halten. Beispiel: a3f1e2d4c5b6a7f8e9d0c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2
•
Öffentlicher Schlüssel64 Hex-Zeichen = 32 Bytes. Das Ergebnis der Multiplikation des Basispunkts auf Curve25519 mit dem privaten Skalar. Kann öffentlich geteilt werden. Beispiel: 5b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8
•
Gemeinsames Geheimnis64 Hex-Zeichen = 32 Bytes. Berechnet als DH(mein_privat, partner_öffentlich) = DH(partner_privat, mein_öffentlich). Diese Gleichheit ist die mathematische Grundlage des Diffie-Hellman-Schlüsselaustauschs.
•
Schlüssel nicht austauschbarX25519- und Ed25519-Schlüssel sehen identisch aus (64 Hex-Zeichen, 32 Bytes), verwenden aber unterschiedliche interne Darstellungen und sind NICHT austauschbar. Verwenden Sie niemals einen Ed25519-Schlüssel als X25519-Schlüssel oder umgekehrt.

X25519 vs. EdDSA (Ed25519)

X25519 und Ed25519 basieren beide auf Curve25519, dienen jedoch völlig unterschiedlichen kryptografischen Zwecken:

•
ZweckX25519: Schlüsselaustausch (Diffie-Hellman). Ed25519: digitale Signaturen (Authentifizierung). Sie können nicht füreinander eingesetzt werden.
•
Mathematische FormX25519 verwendet die Montgomery-Form von Curve25519 für effiziente Skalarmultiplikation. Ed25519 verwendet die verdrillte Edwards-Form. Obwohl birational äquivalent, unterscheiden sich die Schlüsselkodierungen.
•
Schlüssel nicht austauschbarTrotz gleicher Bytelänge sind die Schlüssel NICHT austauschbar. Ein Ed25519-Schlüsselpaar für X25519-DH zu verwenden ist ein kryptografischer Missbrauch, der die Sicherheit gefährden kann.
•
Kombinierter EinsatzIn der Praxis verwenden Protokolle wie Signal beide gemeinsam: X25519 für Schlüsselvereinbarung (Sitzungsschlüssel etablieren) und Ed25519 für Authentifizierung (Signierung des Schlüsselaustauschs zum Schutz vor MITM-Angriffen).
Verwandte Tools: Für digitale Signaturen verwenden Sie das EdDSA (Ed25519) Tool. Für symmetrische Verschlüsselung mit dem gemeinsamen Geheimnis verwenden Sie ChaCha20-Poly1305 oder AES-256-GCM.

FAQ

Q: Was ist der Unterschied zwischen X25519 und ECDH?

A: X25519 ist ECDH — genauer gesagt Elliptic Curve Diffie-Hellman instantiiert über Curve25519, definiert in RFC 7748. Im Vergleich zu ECDH über NIST-Kurven (P-256, P-384) ist X25519 schneller, hat eine einfachere und sicherere Implementierung (keine Kofaktorprobleme, keine Punktvalidierung für typische Eingaben erforderlich) und wurde von Grund auf für Widerstand gegen Implementierungsangriffe entwickelt. Wenn Menschen "ECDH mit Curve25519" sagen, meinen sie X25519.

Q: Können X25519- und Ed25519-Schlüssel austauschbar verwendet werden?

A: Nein. Obwohl X25519 und Ed25519 beide auf Curve25519 basieren, verwenden sie unterschiedliche mathematische Darstellungen (Montgomery-Form vs. verdrillte Edwards-Form) und unterschiedliche Schlüsselkodierungen. Ein X25519-Privatschlüssel ist ein roher 32-Byte-Skalar; ein Ed25519-Privatschlüssel ist ein 32-Byte-Seed, der vor Verwendung gehasht (SHA-512) wird. Obwohl Konvertierungsformeln existieren, ist die austauschbare Verwendung ohne explizite Konvertierung kryptografisch falsch und kann Informationen preisgeben oder ungültige Ergebnisse erzeugen. Generieren Sie immer separate Schlüsselpaare für jeden Zweck.

Q: Wie verschlüssele ich Daten mit dem gemeinsamen Geheimnis?

A: Das 32-Byte X25519-Geheimnis sollte vor der Verwendung als Chiffrierschlüssel durch eine Schlüsselableitungsfunktion (KDF) verarbeitet werden. In der Praxis ist HKDF-SHA256 die häufigste Wahl (verwendet in TLS 1.3, Signal). Übergeben Sie das rohe Geheimnis als Eingabeschlüsselmaterial, fügen Sie protokollspezifischen Salt und Info-String hinzu, und leiten Sie 32 Bytes für AES-256-GCM oder ChaCha20-Poly1305 ab. Für einfache Anwendungsfälle kann das Geheimnis direkt als 32-Byte AES-256-Schlüssel verwendet werden, HKDF wird jedoch in der Produktion dringend empfohlen.

Q: Bietet X25519 Forward Secrecy?

A: Ja — bei Verwendung mit ephemeren Schlüsselpaaren. Forward Secrecy (auch Perfect Forward Secrecy, PFS) bedeutet, dass die Kompromittierung eines langfristigen Schlüssels keine vergangenen Sitzungsschlüssel offenlegt. In TLS 1.3 generieren beide Parteien für jeden Handshake frische X25519-Schlüsselpaare (ephemeres DH). Selbst wenn ein Angreifer später den langfristigen Privatschlüssel eines Servers erhält, kann er zuvor aufgezeichneten Datenverkehr nicht entschlüsseln, da die ephemeren X25519-Schlüssel nach dem Handshake verworfen wurden. Statische (wiederverwendete) X25519-Schlüssel bieten keine Forward Secrecy.

Q: Ist X25519 quantenresistent?

A: Nein — nicht gegen einen ausreichend leistungsstarken Quantencomputer. Ein Quantencomputer, der Shor's Algorithmus ausführt, könnte X25519 brechen, indem er das elliptische Kurven-Diskrete-Logarithmus-Problem in polynomieller Zeit löst. Dies gilt gleichermaßen für alle elliptischen Kurven- und endlichen Feld-Diffie-Hellman-Schemata. Der erforderliche Quantencomputer (tausende fehlerkorrigierter logischer Qubits) existiert jedoch noch nicht. Für Post-Quanten-Schlüsselaustausch hat NIST ML-KEM (früher CRYSTALS-Kyber) standardisiert. TLS 1.3 in Chrome und Firefox setzt bereits hybriden X25519+ML-KEM-Schlüsselaustausch ein.

Use Cases

Empfohlen: TLS 1.3 Schlüsselaustausch

X25519 ist der bevorzugte Schlüsselaustausch-Algorithmus in TLS 1.3 (RFC 8446) und wird von allen großen Browsern und Servern unterstützt. In TLS 1.3 generieren Client und Server jeweils ephemere X25519-Schlüsselpaare, tauschen öffentliche Schlüssel in ClientHello/ServerHello aus und leiten Handshake-Schlüssel mit HKDF ab. Dies bietet Forward Secrecy in einer einzigen Runde. X25519 ersetzte RSA-Schlüsselaustausch und ältere ECDH-Varianten in der obligatorischen Cipher Suite von TLS 1.3.

Recommended Configuration:
  • ✅ TLS 1.3 auf allen Servern aktivieren — X25519 ist automatisch enthalten
  • ✅ X25519 bietet Forward Secrecy in jedem TLS 1.3 Handshake
  • ✅ Nativ unterstützt in OpenSSL, BoringSSL, NSS und allen großen TLS-Bibliotheken
  • ❌ Nicht TLS 1.2 RSA-Schlüsselaustausch verwenden — fehlt Forward Secrecy
Empfohlen: WireGuard VPN

WireGuard verwendet X25519 als einzigen Schlüsselaustauschmechanismus. Jeder WireGuard-Peer hat ein statisches X25519-Schlüsselpaar (zur Authentifizierung) und generiert für jeden Handshake ephemere X25519-Schlüsselpaare (für Forward Secrecy). Das Protokoll verwendet X25519 auch für Preshared-Key-Mischung und setzt das Noise Protocol Framework ein. WireGuards minimalistisches Design — ein Schlüsselaustausch-Algorithmus, eine symmetrische Verschlüsselung (ChaCha20-Poly1305), ein Hash (BLAKE2s) — macht es prüfbar und schnell.

Recommended Configuration:
  • ✅ X25519 ist der einzige Schlüsselaustausch in WireGuard — nichts zu konfigurieren
  • ✅ Statisches Schlüsselpaar generieren: wg genkey | tee private.key | wg pubkey > public.key
  • ✅ WireGuard bietet automatische Forward Secrecy durch ephemere Schlüsselpaare
  • 💡 WireGuard kombiniert: X25519 (Schlüsselaustausch) + ChaCha20-Poly1305 (Verschlüsselung) + BLAKE2s (Hash)
Empfohlen: Ende-zu-Ende-verschlüsselte Nachrichten (Signal, WhatsApp)

Das Signal Protocol (verwendet von Signal, WhatsApp und vielen anderen) nutzt X25519 intensiv in seinem Double Ratchet Algorithm und X3DH (Extended Triple Diffie-Hellman) Schlüsselvereinbarung. X3DH verwendet mehrere X25519-DH-Operationen, um initiale gemeinsame Schlüssel zwischen Parteien zu etablieren, die möglicherweise offline sind. Der Double Ratchet leitet dann kontinuierlich neue Schlüssel aus der X25519-Ratsche ab und bietet sowohl Forward Secrecy als auch Break-in-Recovery. Dies gilt als Goldstandard für sichere Nachrichtenübermittlung.

Recommended Configuration:
  • ✅ X25519 ist die Grundlage der Signal-Protokoll-Schlüsselvereinbarung
  • ✅ X3DH ermöglicht asynchrone Schlüsseleinrichtung (eine Partei kann offline sein)
  • ✅ Double Ratchet + X25519 bietet Forward Secrecy und Post-Compromise-Sicherheit
  • 💡 WhatsApp, Wire, Facebook Messenger Secret Chats verwenden alle Signal Protocol
Empfohlen: Hybridverschlüsselung (Schlüsselkapselung)

Hybridverschlüsselung verwendet X25519 zum Aufbau eines gemeinsamen Geheimnisses und verschlüsselt dann die eigentlichen Daten mit einer symmetrischen Verschlüsselung. Dieses Muster (ECIES oder HPKE — Hybrid Public Key Encryption, RFC 9180) ermöglicht es jedem mit dem X25519-öffentlichen Schlüssel des Empfängers, verschlüsselte Daten ohne vorausgeteilte Geheimnisse zu senden. Der Sender generiert ein ephemeres X25519-Schlüsselpaar, berechnet ein gemeinsames Geheimnis mit dem öffentlichen Schlüssel des Empfängers, leitet einen symmetrischen Schlüssel via HKDF ab, verschlüsselt Daten mit ChaCha20-Poly1305 und sendet den ephemeren öffentlichen Schlüssel zusammen mit dem Chiffretext.

Recommended Configuration:
  • ✅ HPKE (RFC 9180) für standardisierte Hybridverschlüsselung mit X25519 verwenden
  • ✅ Ephemeres Sender-Schlüsselpaar gewährleistet Forward Secrecy für jede Nachricht
  • ✅ Kombination: X25519 (Schlüsselaustausch) + HKDF (Schlüsselableitung) + AES-256-GCM (Verschlüsselung)
  • 💡 Dieses Muster wird von age (Dateiverschlüsselungs-Tool) und Tink-Bibliothek verwendet
Nicht empfohlen: X25519 allein für Vertraulichkeit

X25519 erzeugt nur ein gemeinsames Geheimnis — es verschlüsselt keine Daten. Das gemeinsame Geheimnis selbst ist kein Chiffretext; jede Partei, die die gleiche DH-Berechnung (mit den korrekten Schlüsseln) durchführt, erhält es. Ohne eine darauf angewandte symmetrische Verschlüsselung bleiben Ihre Daten im Klartext. Dies ist ein grundlegender Missbrauch des Algorithmus. Kombinieren Sie X25519 immer mit AES-256-GCM oder ChaCha20-Poly1305, um Daten tatsächlich zu schützen.

Recommended Configuration:
  • ❌ Das X25519 gemeinsame Geheimnis nicht als Chiffretext behandeln — es ist ein Schlüssel, keine verschlüsselten Daten
  • ❌ Schlüsselableitung nicht überspringen — Geheimnis durch HKDF verarbeiten vor Verwendung als Chiffrierschlüssel
  • ✅ X25519 + HKDF + AES-256-GCM ist das korrekte Hybridverschlüsselungsmuster
  • 💡 X25519 löst das Schlüsselverteilungsproblem; symmetrische Verschlüsselung löst Datenvertraulichkeit

Zusammenfassung der Best Practices

  • X25519 ist ein Schlüsselaustausch-Algorithmus — er erzeugt ein gemeinsames Geheimnis, keinen Chiffretext. Immer mit AES-256-GCM oder ChaCha20-Poly1305 kombinieren, um tatsächliche Daten zu verschlüsseln.
  • Das X25519-Geheimnis in Produktionssystemen durch HKDF-SHA256 verarbeiten, bevor es als symmetrischer Chiffrierschlüssel verwendet wird.
  • Ephemere X25519-Schlüsselpaare verwenden (frisches Paar pro Sitzung generieren), um Forward Secrecy zu erreichen.
  • X25519-Schlüssel nicht als Ed25519-Signierschlüssel verwenden und umgekehrt — trotz gleicher Bytelänge unterscheiden sich die internen Darstellungen.
  • X25519 ist der Standard für TLS 1.3, WireGuard und Signal Protocol — für neue Implementierungen gegenüber älterem ECDH-mit-NIST-Kurven bevorzugen.

Diskussion & Feedback

0 Kommentare
Ich