Definition (Glossarkarte): ChaCha20-Poly1305 ist eine Konstruktion für authentifizierte Verschlüsselung mit zugeordneten Daten (AEAD), die die ChaCha20-Stromchiffre mit dem Poly1305-Nachrichtenauthentifizierungscode kombiniert. Sie verschlüsselt den Datenverkehr mit einem 256-Bit-Schlüssel und hängt ein 128-Bit-Authentifizierungs-Tag an, sodass Empfänger Manipulationen in derselben kryptografischen Operation erkennen können.
Wenn eine VPN-App neben WireGuard oder einer TLS-Chiffresuite „ChaCha20-Poly1305“ auflistet, benennt sie den Algorithmus, der die Paketnutzlasten nach dem Handshake tatsächlich schützt. Diesen Namen zu verstehen ist wichtiger, als Marketing-Slogans auswendig zu lernen: ChaCha20-Poly1305 ist kein VPN-Protokoll für sich und kein schwächerer Ersatz für AES. Es ist eine moderne AEAD-Chiffre, die für IETF-Protokolle standardisiert und in WireGuard, TLS, SSH und IPsec weit verbreitet ist.
Woher der Name kommt
Daniel J. Bernstein entwarf Poly1305 (2005) und ChaCha (2008) als schnelle Software-Primitive. Die IETF standardisierte später eine spezifische AEAD-Kombination in RFC 8439 (macht RFC 7539 obsolet): ChaCha20 erzeugt einen Schlüsselstrom, der mit dem Klartext XOR-verknüpft wird, und Poly1305 authentifiziert den Geheimtext sowie alle zugehörigen Daten. Die Konstruktion erweitert den Geheimtext um ein festes 16-Byte-Tag.
Laut der ChaCha20-Poly1305-Wikipedia-Übersicht, nimmt der Algorithmus einen 256-Bit-Schlüssel und eine 96-Bit-Nonce, spiegelt die von AES-GCM bekannte Encrypt-then-MAC-Struktur wider und wird in IPsec, SSH, TLS 1.2/1.3, DTLS und WireGuard eingesetzt. Diese Breite erklärt, warum derselbe Chiffrenname in Verbraucher-VPN-Clients und Unternehmens-Gateways auftaucht.
Wie ChaCha20 verschlüsselt
ChaCha20 ist eine Stromchiffre. Sie teilt Daten nicht in die 128-Bit-Blöcke, die AES verwendet. Stattdessen expandiert sie einen Schlüssel, eine Nonce und einen Blockzähler in 64-Byte-Schlüsselstromblöcke und nutzt dabei nur Addition, XOR und Bitrotation über 20 Runden. Der Schlüsselstrom wird mit dem Klartext XOR-verknüpft, um den Geheimtext zu erzeugen. Die Entschlüsselung ist dasselbe XOR mit demselben Schlüsselstrom.
Protons ChaCha20-Erklärung fasst den praktischen Punkt für VPN-Nutzer zusammen: ChaCha20 ist darauf ausgelegt, in gewöhnlicher Software schnell zu bleiben, was Smartphones, älteren CPUs und Geräten ohne AES-Hardwarebeschleunigung zugutekommt. AES gewinnt oft, wenn AES-NI oder ARM-Kryptoerweiterungen vorhanden sind; ChaCha20 gewinnt oft, wenn die Verschlüsselung in reiner Software mit konsistenten Timing-Eigenschaften laufen muss.
Was Poly1305 hinzufügt
Verschlüsselung allein hindert einen Angreifer nicht daran, Bits während der Übertragung umzukippen. Poly1305 ist ein einmaliger Nachrichtenauthentifizierungscode, der ein 16-Byte-Tag über den Geheimtext (und zugehörige Daten) erzeugt. In der AEAD-Konstruktion von RFC 8439 initialisiert der erste ChaCha20-Block einen einmaligen Poly1305-Schlüssel; spätere Blöcke verschlüsseln die Nutzlast. Wenn die Prüfung des Tags fehlschlägt, muss das Paket verworfen werden, ohne den Klartext freizugeben.
Dieses Modell „zuerst verschlüsseln, dann in einer API authentifizieren“ ist die Bedeutung von AEAD. AES-GCM erledigt dieselbe Aufgabe mit anderen internen Abläufen. Sicherheitsanalysten behandeln korrekt implementiertes ChaCha20-Poly1305 und AES-256-GCM als gleichwertig hinsichtlich Vertraulichkeit und Integrität unter Standardannahmen – solange Nonces für einen gegebenen Schlüssel niemals wiederholt werden.
Warum WireGuard und mobile Stacks das interessiert
Die veröffentlichte Kryptografie von WireGuard legt den Transport-Cipher auf ChaCha20-Poly1305 fest. In klassischem WireGuard gibt es keinen Benutzerschalter für AES. Diese Wahl hält das Protokoll klein und auditierbar: ein AEAD, eine Schlüsselaustauschfamilie, minimale Konfigurationsfläche. OpenVPN und IKEv2/IPsec können mehrere Cipher aushandeln, einschließlich ChaCha20-Poly1305, sofern Bibliotheken und Gegenstellen das unterstützen, weshalb der Algorithmusname auch außerhalb von WireGuard auftaucht.
In Mobilfunknetzen und auf Geräten mit begrenzter Akkulaufzeit sind softwarefreundliche Cipher entscheidend. Historische TLS-Messungen, die im Leistungsanhang von RFC 8439 zitiert werden, zeigten, dass ChaCha20-Poly1305 AES-GCM auf Smartphones ohne AES-Beschleunigung übertraf, während AES-GCM auf Servern mit AES-NI vorn lag. Im Jahr 2026 verfügen viele Smartphones über Krypto-Erweiterungen, aber das softwarefreundliche Design senkt weiterhin das Implementierungsrisiko und hält den Durchsatz über gemischte Flotten hinweg vorhersehbar.
ChaCha20 vs AES: die entscheidenden Abwägungen
- Cipher-Typ: ChaCha20 ist eine Stromchiffre; AES ist eine Blockchiffre, die für AEAD üblicherweise im GCM-Modus betrieben wird.
- Hardware: AES gewinnt typischerweise auf CPUs mit AES-NI / Krypto-Erweiterungen; ChaCha20 gewinnt typischerweise in reiner Software.
- Timing-Seitenkanäle: Das Add-Rotate-XOR-Design von ChaCha20 gilt weithin als einfacher ohne Cache-Timing-Fallstricke zu implementieren als einige tabellenbasierte AES-Softwarepfade.
- Nonce-Disziplin: Sowohl GCM als auch ChaCha20-Poly1305 versagen katastrophal, wenn ein (Schlüssel, Nonce)-Paar wiederverwendet wird. Protokolle müssen Eindeutigkeit garantieren – WireGuard verwendet Paketzähler; TLS leitet pro Record frische Schlüssel und Nonces ab.
- Vertrautheit mit Compliance: Unternehmens-Checklisten nennen nach wie vor häufiger AES-256; das ist institutionelle Gewohnheit, kein Beleg dafür, dass ChaCha20-Poly1305 schwächer wäre, wenn es standardisiert und korrekt eingesetzt wird.
Was ChaCha20-Poly1305 nicht ist
Es ist kein VPN-Protokoll. Es ersetzt weder WireGuard, OpenVPN noch IKEv2. Es verbirgt nicht, dass Sie ein VPN nutzen, wählt keine Exit-Länder und setzt keine No-Logs-Richtlinie durch. Das sind Fragen des Transports, des Routings und des Betreibervertrauens. ChaCha20-Poly1305 beantwortet nur: Sobald Peers einen Sitzungsschlüssel teilen, wie werden Pakete so versiegelt, dass Mithörer sie weder lesen noch unbemerkt verändern können?
Es ist auch nicht „quantensicher“. Wie AES-256-GCM ist es eine symmetrische Chiffre; die übliche Harvest-now-decrypt-later-Sorge bei VPNs gilt dem Handshake-Schlüsselaustausch (heute ECDH, hybride ML-KEM-Einführungen im Entstehen), nicht dem plötzlichen Ablösen von ChaCha20 selbst. Behandeln Sie Post-Quantum-VPN-Behauptungen als Aussagen über Handshakes und Authentifizierung, nicht über den Austausch von ChaCha20 gegen eine andere Bulk-Chiffre.
Praktische Checkliste für Leser
- Wenn Ihr Client WireGuard anzeigt, ist ChaCha20-Poly1305 auf dem Datenkanal konstruktionsbedingt zu erwarten.
- Wenn Ihr Client OpenVPN oder IKEv2 anzeigt, prüfen Sie das ausgehandelte Verfahren in den Logs oder den erweiterten Einstellungen; ChaCha20-Poly1305 kann neben AES-GCM verfügbar sein.
- Jagen Sie nicht dem Adjektiv „military-grade“ hinterher. Bevorzugen Sie dokumentierte AEAD-Suiten aus aktuellen RFCs und gepflegten Clients.
- Denken Sie daran, dass ein starkes AEAD weder ein wiederverwendetes Passwort noch eine Phishing-Seite oder ein DNS-Leak außerhalb des Tunnels behebt.
Kurz gesagt: ChaCha20-Poly1305 ist das AEAD-Arbeitspferd hinter einem Großteil des heutigen VPN- und HTTPS-Verkehrs. Lernen Sie die Definition, kennen Sie die Nonce-Regel und behandeln Sie Protokollwahl und Betreiberrichtlinie als getrennte Fragen vom Namen der Bulk-Chiffre auf dem Einstellungsbildschirm.