Die aktuelle Peer-to-Peer-Kryptografie von Ethereum basiert auf ECDSA/secp256k1. Diese Signaturen sind gegenüber zukünftigen Quantencomputern verwundbar. Ein direkter Austausch von post-quantum Signaturen wie Falcon-512 oder ML-DSA würde jedoch das 1280-Byte-UDP-MTU-Limit von Discv4/Discv5 überschreiten. Deshalb rücken signaturfreie, KEM-basierte Authentifizierungs- und Schlüsselaustauschverfahren in den Fokus, weil sie sowohl Bandbreite als auch Sicherheit effizient adressieren.

Warum klassische Signaturen nicht mehr ausreichen

• Post-Quantum-Signaturen (z. B. Falcon-512) überschreiten das 1280-Byte-UDP-Paketlimit.
• Fragmentierung von Discovery-Paketen erhöht Paketverlust-Raten und Latenz.
• Ein Wechsel zu reinen KEM-Verfahren vermeidet das Fragmentierungsproblem, weil nur ein kurzer Hash-Commitment im Discovery-Layer nötig ist.

Hybrid-KEM X-Wing als Standardlösung

Der hybride KEM X-Wing kombiniert X25519 mit ML-KEM-768. Er ist in der IACR ePrint Archive (Report 2024/039) beschrieben und wird von NIST SP 800-227 (2025) als protokollfähig und sicher gegen klassische sowie quantenbasierte Angriffe bewertet.

Sicherheitsgarantien

• INT-CCA2-Sicherheit beider Komponenten (X25519 und ML-KEM-768).
• Forward Secrecy durch getrennte ephemere KEM-Operationen.
• Explizite Authentifizierung über Schlüsselbestätigung (Key Confirmation).

Größenparameter (2024)

• Chiffretext-Größe: 1120 Bytes (1088 Bytes ML-KEM-768 + 32 Bytes X25519).
• Öffentlicher Schlüssel: 1216 Bytes (1184 Bytes ML-KEM-768 + 32 Bytes X25519).

Bandbreitenvergleich: Legacy vs. KEM-basierte Handshakes

• Legacy RLPx Handshake (2018): 800 Bytes – einfache ECIES-Verschlüsselung und Signatur.
• Protokoll 3 (Double-KEM, 2025): 7800 Bytes – Double-KEM-Kompression (~1440 Bytes Chiffretext) plus zusätzliche Nachrichten.
• Einmaliger Handshake-Overhead ist akzeptabel, da Peer-Verbindungen über Stunden oder Tage bestehen.

Protokollvarianten im Überblick

Protocol 1 – Implizite AKE

• Beide Parteien kapseln zu den statischen KEM-Schlüsseln des Gegenübers.
• Kein Forward Secrecy, nur implizite Authentifizierung.
• Benötigt einen zusätzlichen Round im Vergleich zum ursprünglichen RLPx.

Protocol 2 – Explizite AKE (X-Wing)

• Verwendet langfristige KEM-Schlüssel für Authentifizierung und ephemere KEM-Schlüssel für Forward Secrecy.
• Explizite Schlüsselbestätigung über ein MAC (Key Confirmation) erhöht die Sicherheit.
• Zusätzliche Bestätigungsmeldung (+256 Bytes) führt zu einem Handshake-Volumen von ca. 7 KB.
• Standard-KEM-API, hohe Kryptografie-Agilität.

Protocol 3 – Double-KEM (Maul)

• Komprimiert zwei KEM-Kapselungen in einen einzigen Chiffretext (1440 Bytes).
• Reduziert die Nachrichtengröße von 2528 Bytes auf 1728 Bytes (≈ 40 % Kompression).
• Implementierungsrisiken: Double-KEM ist noch experimentell, keine ausgereifte Software-/Hardware-Unterstützung.
• Benchmarks mit Reinforcing-KEM (RKEM) zeigen einen 9-fachen CPU-Zyklus-Aufwand (48 000 Zyklen vs. 5 400 Zyklen für zwei unabhängige ML-KEM-512).

Risiken im Discovery-Prozess ohne Signaturen

• Verlust der Unverfälschbarkeit: Angreifer können gefälschte Node-Ankündigungen (Peer-Announcement-Poisoning) injizieren.
• Statistiken (Marcus et al., 2018): 17,3 % der Discovery-Pakete waren Ziel von Angriffen.
• Die maximale UDP-Packetgröße für Discv4/5 beträgt 1280 Bytes (IPv6 MTU-Grenze, RFC 8200, 2017).
• Hash-Commitments im UDP-Discovery-Layer reduzieren das Risiko, verschieben jedoch die Verifikation in die TCP-basierte RLPx-Phase.

Rechenaufwand und Implementierungsrisiken

• Rebar-RKEM benötigt 48 000 CPU-Zyklen pro Kapselung (2025), verglichen mit 5 400 Zyklen für zwei unabhängige ML-KEM-512.
• RKEM reduziert den Chiffretext von 1620 Bytes auf 1440 Bytes (≈ 11 % Reduktion).
• Der höhere Rechenaufwand kann durch dominierende Kommunikations-Latenz in der Handshake-Phase relativiert werden.
• Experimentelle KEM-Konstrukte (Double-KEM, Reinforcing-KEM) bergen Stabilitäts- und Kompatibilitätsrisiken.

FAQ

• Warum werden für die Identität im P2P-Netzwerk keine Post-Quantum-Signaturen wie ML-DSA oder Falcon genutzt?
  Post-Quantum-Signaturen überschreiten zusammen mit Payload-Daten das UDP-MTU-Limit von 1280 Bytes, was zu IP-Fragmentierung und hohen Paketverlust-Raten im Discovery-Layer führt.
• Wie garantiert ein KEM-basiertes System Forward Secrecy ohne Signaturen?
  Durch zwei separate KEM-Operationen: eine Kapselung gegen den statischen KEM-Schlüssel (Authentifizierung) und eine gegen einen kurzlebigen ephemeren KEM-Schlüssel, dessen Geheimnis nach der Sitzung verworfen wird.

Fazit

Die Analyse bestätigt, dass hybride KEM-Konstruktionen wie X-Wing (X25519 + ML-KEM-768) die praktischste Migration für Ethereum darstellen. Sie erfüllen die UDP-MTU-Grenze im Discovery-Layer, bieten INT-CCA2-Sicherheit, Forward Secrecy und explizite Authentifizierung, und bleiben dabei innerhalb eines akzeptablen, einmaligen Bandbreiten-Overheads von etwa 7 KB pro Peer-Verbindung. Während Double-KEM-Ansätze die Nachrichtengröße weiter reduzieren, überwiegen derzeit die Implementierungs- und Rechen-Kosten. Für ein langfristig stabiles und sicheres Ethereum-P2P-Netzwerk empfiehlt sich daher Protocol 2 (Explizite AKE) als ausgewogenes Design, das sowohl den Anforderungen der Standardisierungsgremien (NIST SP 800-227, IACR ePrint 2024/039) als auch den praktischen Betriebsbedingungen von Ethereum-Nodes gerecht wird.