AES-256 vs. ChaCha20: Benchmark-Vergleich 2026

Zwei Verschlüsselungsverfahren teilen sich heute den Großteil des verschlüsselten Datenverkehrs im Internet: AES-256 und ChaCha20. Beide verwenden 256-Bit-Schlüssel, beide gelten als sicher gegen praktische Angriffe, und beide stecken in TLS 1.3, VPN-Software und Messaging-Apps, die täglich Milliarden Nutzer öffnen. Trotzdem ist die Wahl zwischen den beiden alles andere als beliebig. Auf einem Intel-Server mit AES-NI-Beschleunigung liefert AES-256-GCM in Benchmarks rund 4.200 MB/s, während ChaCha20-Poly1305 auf derselben Hardware bei etwa 3.800 MB/s liegt. Dreht man das Testfeld um und lässt beide Algorithmen auf einem älteren ARM-Chip ohne Krypto-Erweiterung laufen, kehrt sich das Bild um: ChaCha20 kann hier mehr als 3.000 MB/s pro Kern erreichen, während Software-AES häufig zwischen 200 und 500 MB/s steckenbleibt.

Dieser Vergleich ordnet die aktuellen Zahlen für Leserinnen und Leser in Deutschland, Österreich und der Schweiz ein: mit einer vollständigen Spezifikationstabelle, Benchmarks aus drei unabhängigen Quellen, einem Preisvergleich für Cloud-KMS-Dienste, realen Einsatzbeispielen und einer klaren Empfehlung für unterschiedliche Szenarien. Stand der Daten ist der 15. Oktober 2026.

Beide Verfahren sind seit Jahren öffentlich geprüft, offen dokumentiert und in Hunderten unabhängigen Audits analysiert worden. Keines davon ist proprietär, keines verlangt Lizenzgebühren, und beide laufen in nahezu jeder modernen Kryptobibliothek von OpenSSL bis libsodium. Der Unterschied zwischen ihnen entscheidet sich fast nie an der mathematischen Sicherheit, sondern an der Frage, auf welcher Hardware eine Anwendung tatsächlich läuft, von einem Serverraum in Frankfurt bis zu einem Einstiegssmartphone in einer Zweigstelle in Graz.

Warum AES-256 und ChaCha20 2026 im Mittelpunkt stehen

Die Frage AES-256 oder ChaCha20 ist kein akademisches Gedankenspiel mehr. Wer eine TLS-Verbindung aufbaut, eine VPN-Verbindung herstellt oder eine Festplatte verschlüsselt, trifft diese Entscheidung ständig, meist ohne es zu merken. TLS 1.3 bietet beide Cipher-Suiten standardmäßig an, Browser und Server handeln pro Verbindung aus, welche zum Einsatz kommt. WireGuard setzt ausschließlich auf ChaCha20-Poly1305, während viele Festplattenverschlüsselungen und Behördensysteme auf AES-256-GCM bestehen.

Der Unterschied liegt in der Hardware. AES-256 wurde für Prozessoren mit dedizierten Befehlssätzen entworfen und profitiert massiv von AES-NI, einer Erweiterung, die seit über einem Jahrzehnt in x86-CPUs steckt. ChaCha20 wurde 2008 von Daniel J. Bernstein als reine Software-Chiffre konzipiert, die ohne Spezialhardware schnell läuft und dabei resistent gegen bestimmte Seitenkanalangriffe bleibt. Für Entwickler, die Server, Apps oder IoT-Geräte absichern, ist das kein Detail, sondern eine Entscheidung mit direkten Folgen für Akkulaufzeit, Serverlast und Lizenzkosten.

Für Unternehmen in Deutschland kommt ein dritter Faktor hinzu: Compliance. Banken, Versicherer und Behörden müssen häufig nachweisen, dass eingesetzte Kryptografie in anerkannten, zertifizierten Modulen läuft. AES-256 hat hier einen klaren Vorsprung, weil es seit über zwei Jahrzehnten der De-facto-Standard in FIPS-140-Prüfungen ist. ChaCha20 holt in offenen, performanceorientierten Umgebungen auf, bleibt in streng regulierten Branchen aber die Ausnahme statt die Regel.

AES-256 erklärt: Die etablierte Blockchiffre

AES, der Advanced Encryption Standard, wurde von den belgischen Kryptographen Joan Daemen und Vincent Rijmen entwickelt und 2001 vom US-amerikanischen National Institute of Standards and Technology (NIST) als FIPS 197 standardisiert. AES-256 verschlüsselt Daten in Blöcken von 128 Bit und nutzt einen 256-Bit-Schlüssel über 14 Runden Substitution und Permutation. In der Praxis läuft AES fast immer im GCM-Modus (Galois/Counter Mode), der neben der Verschlüsselung gleich eine Authentifizierung liefert. Diese Kombination heißt AES-256-GCM und ist die Standard-Cipher-Suite in TLS_AES_256_GCM_SHA384.

Der entscheidende Vorteil von AES liegt in der Hardware-Unterstützung. Intel führte AES-NI 2010 in der Westmere-Mikroarchitektur ein, AMD folgte kurz danach. Seitdem beschleunigen praktisch alle modernen Server- und Desktop-CPUs AES-Operationen direkt im Silizium. Das macht AES-256-GCM auf aktueller Server-Hardware zur schnellsten verfügbaren Option. Der Nachteil zeigt sich dort, wo diese Hardware fehlt: auf älteren Smartphones, Mikrocontrollern und einem Teil der Billig-Tablets fällt die Performance deutlich ab, weil die Software-Implementierung von AES vergleichsweise rechenintensiv ist und zusätzlich anfällig für Cache-Timing-Angriffe sein kann, wenn sie nicht konstant-zeitig programmiert wurde.

ChaCha20 erklärt: Die moderne Stream-Chiffre

ChaCha20 ist eine Stromchiffre, die ihren 256-Bit-Schlüssel und einen Nonce-Wert nutzt, um einen Pseudo-Zufallsstrom zu erzeugen, der anschließend per XOR mit dem Klartext verknüpft wird. Entwickelt hat sie Daniel J. Bernstein 2008 als Weiterentwicklung seiner älteren Salsa20-Chiffre. Kombiniert mit dem Poly1305-Authentifizierungscode ergibt sich ChaCha20-Poly1305, standardisiert in RFC 8439 der Internet Engineering Task Force. In TLS 1.3 trägt diese Suite die Bezeichnung TLS_CHACHA20_POLY1305_SHA256.

Der Clou an ChaCha20 ist die Bauweise: Sie verwendet ausschließlich Additionen, Rotationen und XOR-Operationen auf 32-Bit-Wörtern, Befehle, die jeder Prozessor nativ und schnell ausführt, egal ob x86, ARM oder ein günstiger Mikrocontroller. Dadurch bleibt die Performance konstant und vorhersagbar, ganz ohne Spezialbefehle. Das macht ChaCha20 zur bevorzugten Wahl für mobile Geräte ohne AES-Beschleunigung, für eingebettete Systeme und für Protokolle wie WireGuard, die portabel und schnell auf allen Plattformen laufen sollen.

Implementierung in der Praxis: Bibliotheken und Programmiersprachen

Entwickler müssen beide Algorithmen selten selbst implementieren, praktisch jede moderne Sprache bringt fertige, auditierte Bausteine mit. OpenSSL und die davon abgeleitete BoringSSL von Google unterstützen seit Jahren sowohl AES-256-GCM als auch ChaCha20-Poly1305 über dieselbe API, genauso wie libsodium, die Bibliothek, die Signal und viele andere Messenger für kryptografische Grundoperationen nutzen. In Node.js steht ChaCha20-Poly1305 über das integrierte crypto-Modul als chacha20-poly1305-Cipher zur Verfügung, AES-256-GCM über aes-256-gcm. Python-Entwickler greifen meist zur cryptography-Bibliothek, die beide AEAD-Chiffren mit identischer Schnittstelle anbietet. Go-Programmierer finden ChaCha20-Poly1305 im Paket golang.org/x/crypto/chacha20poly1305 und AES-GCM direkt in der Standardbibliothek crypto/cipher.

# Node.js: beide AEAD-Chiffren ueber dieselbe crypto-API
const crypto = require('crypto');

// AES-256-GCM
const cipherAES = crypto.createCipheriv('aes-256-gcm', key32, nonce12);

// ChaCha20-Poly1305
const cipherChaCha = crypto.createCipheriv('chacha20-poly1305', key32, nonce12, { authTagLength: 16 });

Der praktische Vorteil dieser Vereinheitlichung: Ein Wechsel zwischen den beiden Algorithmen bleibt meist eine Konfigurationsfrage, nicht ein Architekturprojekt. Wer heute AES-256-GCM einsetzt, kann ChaCha20-Poly1305 in der Regel mit wenigen Zeilen Code parallel anbieten, ohne die restliche Anwendungslogik anzufassen.

Bei der Auswahl einer Bibliothek lohnt sich zusätzlich ein Blick auf die Update-Historie und die Anzahl unabhängiger Sicherheitsaudits. OpenSSL und libsodium gehören zu den am häufigsten geprüften Kryptobibliotheken überhaupt, was das Risiko unentdeckter Implementierungsfehler deutlich senkt. Wer eine selten gepflegte oder unauditierte Drittanbieter-Bibliothek einsetzt, riskiert, dass selbst ein mathematisch einwandfreier Algorithmus wie AES-256 oder ChaCha20 durch einen simplen Programmierfehler seine Schutzwirkung verliert.

Die Geschichte: Vom AES-Wettbewerb zur modernen Stromchiffre

AES entstand nicht im stillen Kämmerlein, sondern aus einem offenen Wettbewerb, den das NIST 1997 ausschrieb, um einen Nachfolger für den veralteten Data Encryption Standard (DES) zu finden. Fünfzehn Kandidaten aus aller Welt traten an, darunter bekannte Namen wie Twofish und Serpent. Am Ende setzte sich 2000 der belgische Entwurf Rijndael durch, benannt nach seinen Erfindern Rijmen und Daemen, und wurde 2001 offiziell als FIPS 197 standardisiert. Dieser transparente Auswahlprozess gilt bis heute als Vorbild dafür, wie öffentliche Kryptografie-Standards entstehen sollten, und ist einer der Gründe, warum AES so breites Vertrauen genießt.

ChaCha20 hat eine andere, direktere Entstehungsgeschichte. Daniel J. Bernstein entwickelte 2005 zunächst Salsa20 als Beitrag zum europäischen eSTREAM-Wettbewerb für Stromchiffren. 2008 veröffentlichte er mit ChaCha eine verbesserte Variante, die eine stärkere Diffusion pro Runde bietet und dadurch bei gleicher Rundenzahl ein höheres Sicherheitsniveau erreicht. Google übernahm ChaCha20 ab 2013 zunächst für Chrome auf mobilen Geräten, kombinierte es mit Poly1305 und trieb darüber die Standardisierung in der IETF voran, die 2015 mit RFC 7539 und später mit dem aktualisierten RFC 8439 abgeschlossen wurde. Anders als AES durchlief ChaCha20 also keinen formalen Regierungswettbewerb, sondern setzte sich durch breite Praxisnutzung und offene Begutachtung durch die Kryptografie-Community durch.

Technische Spezifikationen im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten technischen Eigenschaften beider Verfahren zusammen, von der Schlüssellänge bis zur Standardisierung.

Eigenschaft	AES-256	ChaCha20
Typ	Blockchiffre	Stromchiffre
Schlüssellänge	256 Bit	256 Bit
Blockgröße / interner Zustand	128 Bit pro Block	512-Bit-Zustand, 64-Byte-Keystream-Block
Entwickelt von	Joan Daemen, Vincent Rijmen (1998)	Daniel J. Bernstein (2008)
Standardisierung	NIST FIPS 197 (2001)	IETF RFC 8439 (2018, mit Poly1305)
Übliche AEAD-Variante	AES-256-GCM	ChaCha20-Poly1305
TLS-1.3-Cipher-Suite	TLS_AES_256_GCM_SHA384	TLS_CHACHA20_POLY1305_SHA256
Hardware-Beschleunigung	AES-NI (x86), ARMv8 Crypto Extensions	Keine dedizierte Hardware nötig
Durchsatz mit Hardware-Beschleunigung	ca. 4.200 MB/s	ca. 3.800 MB/s
Durchsatz ohne Hardware-Beschleunigung	ca. 200–500 MB/s	über 3.000 MB/s pro Kern
Seitenkanalresistenz ohne Hardwarehilfe	Abhängig von Implementierung, anfällig für Cache-Timing	Konstant-zeitig durch Bauweise
Bekannte praktische Angriffe auf volle Schlüssellänge	Keine	Keine
Typisches Einsatzgebiet	FIPS-Umgebungen, Festplattenverschlüsselung, Server-TLS	WireGuard, mobile Apps, OpenSSH

Auffällig: Bei reiner Rechenleistung mit Hardware-Unterstützung liegen beide Verfahren nah beieinander. Der wirkliche Unterschied entsteht erst, wenn die Hardware-Beschleunigung fehlt, und genau das zeigt der nächste Abschnitt im Detail.

AES-128 versus AES-256: Warum die Schlüssellänge hier zählt

Dieser Vergleich konzentriert sich bewusst auf AES-256 statt auf die ebenfalls verbreitete 128-Bit-Variante, weil ChaCha20 praktisch immer mit einem 256-Bit-Schlüssel eingesetzt wird und ein fairer Vergleich gleiche Schlüssellängen voraussetzt. AES-128 ist technisch schneller als AES-256, weil es nur zehn statt vierzehn Runden durchläuft, bietet dafür aber eine geringere Sicherheitsmarge. Für die meisten praktischen Zwecke gilt AES-128 bereits als ausreichend sicher, viele Organisationen entscheiden sich trotzdem für AES-256, um auch langfristig und gegenüber zukünftigen Angriffsverbesserungen auf der sicheren Seite zu bleiben.

TLS 1.3 schreibt AES-128-GCM als verpflichtende Mindestunterstützung vor, lässt Servern aber die Freiheit, zusätzlich AES-256-GCM oder ChaCha20-Poly1305 anzubieten. In der Praxis bedeutet das: Ein Server kann technisch mit der schnelleren 128-Bit-Variante arbeiten und trotzdem die höhere Sicherheitsstufe für Kunden bereithalten, die sie explizit anfordern, etwa aus regulatorischen Gründen. Für den direkten Vergleich mit ChaCha20, das stets mit vollen 256 Bit arbeitet, ist AES-256 deshalb die einzig sinnvolle Vergleichsbasis, auch wenn AES-128 im Alltag weiterhin eine relevante, schnellere Option bleibt.

Performance-Benchmarks: Drei Testreihen im Überblick

Durchsatzwerte für Verschlüsselung hängen stark von CPU-Modell, OpenSSL-Version, Paketgröße und Testaufbau ab. Deshalb lohnt sich der Blick auf mehrere unabhängige Messungen statt auf eine einzelne Zahl.

Bare-Metal-Server mit AES-NI

Eine Benchmark-Reihe von p42.studio zu Web-Automatisierungsszenarien misst auf Bare-Metal-Systemen mit aktivierter AES-NI-Beschleunigung rund 4.200 MB/s für AES-256-GCM gegenüber etwa 3.800 MB/s für ChaCha20-Poly1305. AES liegt hier also leicht vorn, der Abstand bleibt aber moderat bei rund zehn Prozent. Für Server-Workloads mit viel TLS-Traffic auf aktueller Hardware macht das AES-256-GCM zur effizienteren Standardwahl.

ARM-Geräte und Systeme ohne AES-NI

Ganz anders sieht es aus, sobald die AES-Hardwarebeschleunigung fehlt. Eine Analyse von DapriPro zu älteren ARM-Prozessoren, Budget-Smartphones und IoT-Geräten ohne AES-NI zeigt, dass Software-optimiertes AES-256-GCM dort auf etwa 200 bis 500 MB/s fällt. ChaCha20-Poly1305 erreicht auf derselben Geräteklasse mehr als 3.000 MB/s pro Kern, also ein Vielfaches des AES-Durchsatzes. Das erklärt, warum Entwickler mobiler Apps und IoT-Firmware ChaCha20 oft gezielt wählen.

Software-Only-Vergleich mit deaktivierter AES-NI

Eine Studie der ukrainischen Fachpublikation Information Technologies and Computer Engineering (itce.vn.ua) hat AES-NI gezielt deaktiviert und beide Algorithmen rein in Software laufen lassen. Das Ergebnis: ChaCha20-Poly1305 war drei- bis vierfach schneller als AES-256-GCM. Bei mobilen Testszenarien in derselben Studie erreichte ChaCha20 ungefähr 300 bis 500 MB/s pro Kern, während AES-GCM ohne Hardware-Unterstützung nur 100 bis 150 MB/s schaffte. Alle drei Quellen bestätigen damit dasselbe Muster, auch wenn die absoluten Zahlen je nach Testaufbau schwanken: Mit AES-NI führt AES knapp, ohne AES-NI gewinnt ChaCha20 deutlich.

Benchmark selbst durchführen: OpenSSL speed in der Praxis

Wer die Zahlen aus diesem Artikel auf eigener Hardware nachprüfen möchte, braucht dafür kein spezielles Testlabor. OpenSSL bringt mit openssl speed ein eingebautes Benchmark-Werkzeug mit, das Durchsatzwerte für verschiedene Algorithmen direkt auf der Zielmaschine misst. Der folgende Befehl testet AES-256-GCM und ChaCha20-Poly1305 nacheinander mit unterschiedlichen Paketgrößen.

# Durchsatz fuer AES-256-GCM und ChaCha20-Poly1305 messen
openssl speed -evp aes-256-gcm
openssl speed -evp chacha20-poly1305

# AES-NI gezielt deaktivieren, um Software-Performance zu testen
OPENSSL_ia32cap="~0x200000200000000" openssl speed -evp aes-256-gcm

Die Ausgabe zeigt den Durchsatz in Byte pro Sekunde für unterschiedliche Blockgrößen, typischerweise von 16 Byte bis 16 Kilobyte. Wichtig für eine faire Einordnung: Das Ergebnis hängt stark vom genutzten OpenSSL-Build, der CPU-Generation und davon ab, ob AES-NI tatsächlich aktiv ist. Wer die eigenen Zahlen mit den in diesem Artikel genannten Werten vergleicht, sollte deshalb nicht einzelne Messungen, sondern das grundsätzliche Muster betrachten: Mit Hardware-Beschleunigung liegt AES vorn, ohne sie übernimmt ChaCha20 die Führung.

Sicherheit und bekannte Schwachstellen

Für beide Algorithmen gibt es derzeit keine praktischen Angriffe, die den vollen Schlüsselraum brechen. Die realen Risiken liegen fast immer in der Umsetzung, nicht im mathematischen Kern. Bei AES-256 betreffen diese Risiken vor allem Fehlkonfigurationen im GCM-Modus, etwa die Wiederverwendung eines Nonce-Werts, was die Vertraulichkeit und Integrität der gesamten Verschlüsselung untergraben kann. Hinzu kommen Seitenkanalangriffe über Cache-Timing bei Software-Implementierungen ohne AES-NI, ein Problem, das bei Hardware-beschleunigten Varianten praktisch verschwindet.

ChaCha20 wurde von Grund auf so entworfen, dass es ohne Lookup-Tabellen arbeitet und dadurch von Natur aus resistenter gegen bestimmte Cache-Timing-Angriffe ist, unabhängig davon, ob Spezialhardware vorhanden ist. Auch hier gilt: Eine wiederverwendete Nonce bei ChaCha20-Poly1305 kann die Sicherheit komplett aushebeln, weil der erzeugte Keystream dann vorhersagbar wird. Für regulierte Branchen wie Banken, Behörden und Gesundheitswesen bleibt AES-256-GCM in Deutschland und der gesamten DACH-Region meist die einfachere Wahl, weil es in NIST-validierten Modulen und etablierten Compliance-Rahmenwerken breiter verankert ist als ChaCha20.

Kryptoanalytiker untersuchen beide Algorithmen seit Jahren mit reduzierten Rundenzahlen, um Schwachstellen frühzeitig zu erkennen. Bei AES-256 sind bislang nur theoretische Angriffe auf eine stark verkürzte Rundenzahl bekannt, die weit unter den tatsächlich genutzten 14 Runden liegen und keine praktische Relevanz haben. Bei ChaCha20 sehen Forscher ein ähnliches Bild: Differenzielle Kryptoanalyse erreicht bislang nur einen Teil der vollen 20 Runden, ohne den vollständigen Algorithmus zu gefährden. Für beide Verfahren gilt deshalb, dass die Sicherheitsmarge aktuell komfortabel groß ist und sich eher in der korrekten Implementierung als im Algorithmus selbst entscheidet.

TLS 1.3 und die Rolle in Browsern

TLS 1.3 schreibt die Unterstützung von AES-128-GCM als Mindeststandard vor, bietet aber zusätzlich AES-256-GCM und ChaCha20-Poly1305 als gleichwertige, verhandelbare Optionen an. Beim Verbindungsaufbau einigen sich Client und Server in Millisekunden auf die stärkste gemeinsam unterstützte Suite. Laut einer 2026 veröffentlichten Markterhebung liegt die TLS-1.3-Verbreitung inzwischen bei rund 83 Prozent des gesamten TLS-Datenverkehrs, mit einer ungefähren Aufteilung von 42 Prozent auf TLS_AES_128_GCM_SHA256, 28 Prozent auf TLS_AES_256_GCM_SHA384 und 13 Prozent auf TLS_CHACHA20_POLY1305_SHA256. Diese Verteilung stammt aus einer einzelnen Markterhebung und sollte nicht als offizielle IETF- oder Browser-Statistik missverstanden werden, zeigt aber die grobe Größenordnung: AES-Varianten dominieren den TLS-Verkehr insgesamt, ChaCha20-Poly1305 bleibt die wichtige Nische für mobile und hardwareschwache Clients.

Browser-Hersteller entscheiden sich bewusst für diese Flexibilität. Ein Smartphone ohne AES-Beschleunigung kann eine Verbindung bevorzugt mit ChaCha20-Poly1305 aushandeln, während ein Server-Cluster mit modernen Xeon-Prozessoren automatisch zu AES-256-GCM wechselt. Für Website-Betreiber bedeutet das: Die Cipher-Suite-Reihenfolge in der eigenen TLS-Konfiguration sollte beide Optionen enthalten, damit jeder Client die für sein Gerät schnellste Variante bekommt.

WireGuard, OpenSSH und VPN-Protokolle

WireGuard, das schnelle VPN-Protokoll, das inzwischen im Linux-Kernel integriert ist, verzichtet komplett auf Verhandlungsspielraum und setzt ausschließlich auf ChaCha20 für die Verschlüsselung und Poly1305 für die Authentifizierung. Diese Entscheidung der Entwickler ist kein Zufall: WireGuard soll auf möglichst vielen Geräten, von Raspberry-Pi-Routern bis zu Smartphones, konstant schnell laufen, ohne auf spezifische Prozessor-Erweiterungen angewiesen zu sein.

OpenSSH geht den flexibleren Weg und bietet beide Verfahren parallel an: [email protected] für Systeme mit AES-Beschleunigung und [email protected] für alle anderen Fälle. Administratoren, die SSH-Verbindungen auf älteren Embedded-Systemen oder Routern absichern, greifen deshalb häufig gezielt zu ChaCha20-Poly1305, selbst wenn der Server selbst AES-NI besitzt, einfach weil die Gegenseite davon nicht profitiert.

Auch große Infrastrukturanbieter spiegeln diese Zweiteilung in ihren Standardkonfigurationen. Content-Delivery-Netzwerke und große Cloud-Plattformen aktivieren beide Cipher-Suiten in ihren TLS-Terminierungspunkten, damit ein Nutzer mit einem aktuellen Business-Notebook ebenso effizient bedient wird wie jemand mit einem älteren Einsteiger-Smartphone in einem Funkloch mit schwacher Verbindung. Diese Praxis, beide Algorithmen gleichzeitig vorzuhalten statt sich auf einen festzulegen, hat sich über die vergangenen Jahre als praktischer Industriestandard etabliert und findet sich inzwischen in den Standardeinstellungen praktisch jedes gängigen Webservers.

Mobile Geräte: Warum Android häufig auf ChaCha20 setzt

Android-nahe Empfehlungen bevorzugen ChaCha20-Poly1305 typischerweise auf Geräten ohne effiziente AES-Hardware, etwa in günstigeren Smartphone-Chipsätzen oder älteren Modellen, während AES-GCM auf aktuellen Chips mit AES-Erweiterung konkurrenzfähig oder sogar schneller bleibt. Für App-Entwickler, die eine breite Gerätepalette abdecken müssen, von High-End-Flaggschiffen bis zu Einsteigermodellen für den DACH-Markt, ist das ein praktischer Grund, ChaCha20-Poly1305 als Fallback einzuplanen statt sich allein auf AES zu verlassen.

Der Effekt wirkt sich direkt auf die Akkulaufzeit aus. Eine Stromchiffre, die ohne Spezialhardware schnell läuft, verbraucht pro verschlüsseltem Megabyte weniger Rechenzyklen als eine Blockchiffre, die auf Software-Tabellen zurückgreifen muss. Bei datenintensiven Apps, etwa Video-Streaming oder Cloud-Backup-Tools, kann diese Differenz über den Tag messbar im Energieverbrauch auffallen.

Energieverbrauch und Akkulaufzeit im Detail

Rechenzyklen kosten Strom, und bei mobilen Geräten übersetzt sich das direkt in Akkulaufzeit. Fehlt die AES-Hardwarebeschleunigung, muss die CPU für jeden verschlüsselten Block mehrere Lookup-Tabellen durchlaufen, was mehr Taktzyklen und damit mehr Energie pro Megabyte benötigt als eine Stromchiffre, die nur einfache Additionen und Rotationen ausführt. Bei einer App, die kontinuierlich Daten verschlüsselt, etwa ein Cloud-Backup-Tool oder ein Video-Chat, kann sich dieser Unterschied über eine Nutzungsstunde in einem spürbar höheren Akkuverbrauch niederschlagen, besonders auf älteren oder günstigeren Chipsätzen ohne Krypto-Erweiterung.

Für Gerätehersteller und App-Entwickler im DACH-Raum, die eine breite Nutzerbasis mit unterschiedlich alten Smartphones bedienen, ist das ein handfestes Produktargument: Eine Verschlüsselung, die auf dem Einstiegsmodell weniger Akku zieht, verbessert direkt die Nutzererfahrung, ohne dass die Sicherheit leidet. Deshalb lohnt sich bei Apps mit großer Reichweite fast immer eine automatische Auswahl der Chiffre je nach Zielgerät statt einer festen, geräteunabhängigen Vorgabe.

Post-Quanten-Perspektive: Bleiben beide Verfahren relevant?

Während asymmetrische Verfahren wie RSA und klassische elliptische Kurven durch Quantencomputer grundsätzlich angreifbar wären, sieht die Lage bei symmetrischen Chiffren wie AES-256 und ChaCha20 deutlich entspannter aus. Der relevante Quantenalgorithmus für symmetrische Verschlüsselung ist Grovers Algorithmus, der die effektive Sicherheit eines Schlüssels ungefähr halbiert. Bei einem 256-Bit-Schlüssel bleibt nach dieser Halbierung immer noch eine effektive Sicherheit von etwa 128 Bit übrig, ein Wert, der nach heutigem Kenntnisstand für Jahrzehnte als praktisch unangreifbar gilt.

Das erklärt, warum Sicherheitsbehörden und Standardisierungsgremien AES-256 und ChaCha20 im Gegensatz zu RSA und klassischer elliptischer Kurvenkryptographie nicht auf der dringenden Migrationsliste für die Post-Quanten-Ära führen. Der eigentliche Umbau findet bei den asymmetrischen Schlüsselaustausch- und Signaturverfahren statt, die zunehmend durch neue, quantenresistente Algorithmen wie ML-KEM oder ML-DSA ersetzt werden. AES-256 und ChaCha20 bleiben in diesem Übergang die stabile, kaum veränderte Basis für die eigentliche Datenverschlüsselung, während sich die Diskussion um Schlüsselaustausch und digitale Signaturen weiterdreht.

Fünf reale Einsatzbeispiele aus der Praxis

Die folgenden Beispiele zeigen, wie unterschiedlich Produkte und Protokolle die Wahl zwischen beiden Verfahren in der Praxis treffen, meist orientiert an der erwarteten Zielhardware und den Compliance-Anforderungen der jeweiligen Branche.

WireGuard-VPN: Setzt ausnahmslos auf ChaCha20-Poly1305 für alle Tunnel, unabhängig von der Client-Hardware.
TLS-1.3-Webserver: Nginx- und Apache-Konfigurationen bieten standardmäßig beide Cipher-Suiten an und lassen den Client die schnellere Option wählen.
OpenSSH-Verbindungen: Administratoren nutzen [email protected] gezielt für Verbindungen zu Embedded-Geräten und Routern ohne AES-Beschleunigung.
Cloud-Festplattenverschlüsselung: AWS KMS und Google Cloud KMS verwalten standardmäßig AES-256-Schlüssel für Daten im Ruhezustand, weil Server-Hardware dort fast immer AES-NI bietet.
Signal-Protokoll: Nutzt ChaCha20-Poly1305 beziehungsweise verwandte AEAD-Konstruktionen für eine gleichmäßige Performance über heterogene Smartphones hinweg.
FIPS-regulierte Behördensysteme: Setzen in Deutschland und der EU meist verpflichtend auf AES-256-GCM, weil es in zertifizierten NIST-Modulen verfügbar ist.
Festplattenverschlüsselung auf Laptops: Windows-BitLocker und das Open-Source-Tool VeraCrypt setzen standardmäßig auf AES-256, weil moderne Laptop-Prozessoren die Last über AES-NI praktisch ohne Performanceverlust übernehmen.
Datenbank- und Storage-Verschlüsselung: Große Cloud-Datenbankdienste verschlüsseln Daten im Ruhezustand standardmäßig mit AES-256-GCM, weil die zugrunde liegenden Server-Flotten durchgängig AES-NI besitzen.

Preisvergleich: Was AES-256 und ChaCha20 in der Cloud kosten

Beide Algorithmen selbst sind offene, lizenzfreie Standards. Kosten entstehen erst durch die Infrastruktur, die Schlüssel verwaltet. Cloud-Anbieter bieten dafür praktisch ausschließlich AES-basierte Schlüsselverwaltung an, ChaCha20 wird in Cloud-KMS-Diensten kaum als eigenständiges Produkt vermarktet, sondern meist direkt in Protokollen wie WireGuard oder TLS-Bibliotheken implementiert, ohne separate Abrechnung. Das bedeutet nicht, dass ChaCha20 in der Cloud nichts kostet, die Kosten verschieben sich lediglich: Sie fallen über die allgemeine Rechenzeit der Server an, nicht über eine eigene Zeile auf der Cloud-Rechnung.

Für Teams, die ihre monatliche Cloud-Rechnung im Blick behalten müssen, lohnt sich deshalb ein Blick auf beide Kostenarten gemeinsam: die expliziten KMS-Gebühren für AES-Schlüssel und die implizite Rechenlast, die ChaCha20 auf den ohnehin laufenden Servern erzeugt. Bei sehr hohem Traffic-Volumen kann die zweite Variante am Ende günstiger ausfallen, weil keine zusätzliche Gebühr pro Vorgang anfällt, solange die vorhandene Serverkapazität die zusätzliche Last noch abfedert.

Dienst	Preismodell	Ungefährer Preis
AWS KMS – Schlüsselverwaltung	Pro Schlüssel, pro Monat	1,00 US-Dollar, anteilig nach Stunden
AWS KMS – API-Anfragen	Nach Freikontingent	20.000 Anfragen/Monat gratis, danach ca. 0,03 US-Dollar pro 10.000 Anfragen
Google Cloud KMS – kryptografische Vorgänge	Pro 10.000 Operationen	ca. 0,03 US-Dollar
Google Cloud KMS – Software-Schlüsselversion	Pro Schlüsselversion	ca. 0,06 US-Dollar
Google Cloud KMS – HSM-Schlüsselversion	Pro aktive Schlüsselversion, pro Monat	ca. 1,00–2,50 US-Dollar
Azure Key Vault	Pro Vorgang	Keine zuverlässig aktuelle Angabe gefunden, siehe aktuelle Microsoft-Preisliste
Selbstgehostet (OpenSSL, libsodium)	Open Source	0 Euro Lizenzkosten, nur Infrastrukturkosten
WireGuard-VPN	Offenes Protokoll	0 Euro, Kosten entstehen nur durch Serverbetrieb

Der Preisunterschied zwischen AWS KMS und Google Cloud KMS bleibt bei niedrigem Volumen gering. Relevant wird er erst bei Millionen von Verschlüsselungsvorgängen pro Monat, wo sich Unterschiede im API-Preis pro 10.000 Anfragen in echten Kosten niederschlagen. Für Unternehmen mit umfangreicher Schlüsselverwaltung lohnt sich deshalb ein genauer Blick auf die eigene Zugriffsrate, bevor sie sich für einen Anbieter entscheiden.

Wer komplett auf eigene Infrastruktur setzt, zahlt weder für Schlüssel noch für einzelne Verschlüsselungsvorgänge, trägt dafür aber die volle Verantwortung für Schlüsselrotation, Backups und physischen Zugriffsschutz, etwa über ein eigenes Hardware-Sicherheitsmodul (HSM). Für kleinere Teams und Start-ups in der DACH-Region ist der verwaltete Cloud-KMS-Dienst deshalb trotz der laufenden Kosten oft die praktischere Lösung, weil Zertifizierung, Rotation und Zugriffskontrolle bereits mitgeliefert werden. Größere Unternehmen mit eigenem Sicherheitsteam rechnen dagegen häufig durch, ab welchem Verschlüsselungsvolumen sich ein eigenes HSM gegenüber den laufenden Cloud-Gebühren amortisiert.

BSI- und NIST-Empfehlungen für die DACH-Region

Für FIPS- und stark regulierte Umgebungen bleibt AES-256-GCM meist die einfachere Wahl, weil AES in etablierten NIST-validierten Kryptografiemodulen und Cloud-KMS-Angeboten breit verfügbar ist. Für Organisationen in Deutschland bedeutet das: Wer Vorgaben wie das IT-Grundschutz-Kompendium oder branchenspezifische Zertifizierungen erfüllen muss, trifft mit AES-256-GCM häufig die Option mit dem geringsten Zertifizierungsaufwand, weil Prüfstellen und Auditoren mit diesem Standard am vertrautesten sind. Das Bundesamt für Sicherheit in der Informationstechnik veröffentlicht regelmäßig technische Richtlinien zu kryptografischen Verfahren, in denen AES als etablierter Blockchiffre-Standard eine zentrale Rolle einnimmt. Unternehmen, die öffentliche Aufträge in Deutschland bedienen, sollten deshalb vor einer finalen Festlegung die jeweils aktuelle Fassung dieser Richtlinien konsultieren, statt sich allein auf internationale Empfehlungen zu stützen.

Das schließt ChaCha20-Poly1305 nicht aus, es verschiebt nur den Prüfaufwand. Für Entwickler in Österreich und der Schweiz, die mobile Apps oder IoT-Produkte bauen und keine FIPS-Zertifizierung benötigen, bleibt ChaCha20-Poly1305 technisch die performantere und auf schwächerer Hardware oft auch die sicherere Option, weil sie weniger anfällig für implementierungsbedingte Seitenkanalprobleme ist.

In der Schweiz orientieren sich viele Unternehmen zusätzlich an internationalen Normen wie ISO/IEC 19790, die ähnliche Anforderungen an validierte Kryptomodule stellt wie die US-amerikanischen FIPS-Vorgaben. Für österreichische Betriebe, die mit deutschen oder EU-weiten Partnern zusammenarbeiten, gilt in der Praxis meist die strengere der beiden Vorgaben als Richtschnur. Wer unsicher ist, welche Variante im eigenen Umfeld Pflicht ist, sollte frühzeitig die jeweilige nationale Aufsichtsbehörde oder einen spezialisierten Prüfdienstleister einbinden, statt sich allein auf allgemeine Kryptografie-Empfehlungen zu verlassen.

Vor- und Nachteile im Überblick

AES-256-GCM

Schnellste Option auf praktisch jeder modernen Server- und Desktop-CPU mit AES-NI
Breite Verfügbarkeit in FIPS-validierten Modulen und Cloud-KMS-Diensten
Jahrzehntelange Praxiserfahrung und tiefe Integration in Compliance-Rahmenwerke
Deutlich langsamer ohne Hardware-Beschleunigung, teils anfällig für Cache-Timing-Angriffe in schlecht implementierter Software
Höherer Energieverbrauch auf Geräten ohne AES-Erweiterung

ChaCha20-Poly1305

Konstant schnelle, vorhersagbare Performance unabhängig von der Hardware
Von Natur aus resistent gegen bestimmte Cache-Timing-Seitenkanäle
Ideal für mobile Geräte, IoT und Embedded-Systeme ohne Krypto-Erweiterungen
Auf aktueller Server-Hardware mit AES-NI meist etwas langsamer als AES-256-GCM
Weniger verbreitet in FIPS-zertifizierten Modulen, was Compliance-Prüfungen erschweren kann

Welcher Algorithmus passt zu welchem Einsatzfall

Die Benchmark-Daten liefern eine klare Richtung für die Praxis. Die folgenden Empfehlungen orientieren sich an der jeweiligen Hardware und dem Compliance-Bedarf, nicht an einer pauschalen Präferenz für einen der beiden Algorithmen.

Server-TLS auf moderner Intel/AMD-Hardware: AES-256-GCM, wegen des Durchsatzvorteils mit AES-NI.
Mobile Apps für ein breites Android-Gerätespektrum: ChaCha20-Poly1305 als primäre oder Fallback-Option für Geräte ohne AES-Beschleunigung.
VPN-Infrastruktur: WireGuard mit ChaCha20-Poly1305, wenn Portabilität und konstante Performance über viele Gerätetypen wichtiger sind als der letzte Prozentpunkt Serverleistung.
Behörden, Banken, Gesundheitswesen mit FIPS-Pflicht: AES-256-GCM, wegen der breiteren Verfügbarkeit in zertifizierten Modulen.
IoT-Geräte und Mikrocontroller ohne Krypto-Erweiterung: ChaCha20-Poly1305, wegen des Durchsatzvorteils ohne Spezialhardware.
Festplatten- und Backup-Verschlüsselung auf Laptops mit AES-NI: AES-256, weil moderne Laptop-CPUs die Last praktisch kostenlos übernehmen.
Cross-Plattform-Messaging-Apps: ChaCha20-Poly1305, um auf allen Endgeräten eine gleichmäßige Performance zu garantieren.

Wer sich bei der eigenen Architektur nicht sofort festlegen will, fährt mit beiden Optionen parallel am sichersten: TLS 1.3, OpenSSH und die meisten modernen Kryptobibliotheken erlauben, beide Cipher-Suiten gleichzeitig anzubieten und die endgültige Wahl automatisch der Zielhardware zu überlassen, statt eine Entscheidung zu erzwingen, die nicht zu jedem Endgerät passt.

Migrationsleitfaden: Cipher-Suite in der Praxis wechseln

Ein Wechsel der bevorzugten Cipher-Suite erfordert selten einen Codeumbau, meist reicht eine Konfigurationsänderung. Diese Schritte zeigen den typischen Ablauf für einen Nginx-Webserver und einen SSH-Dienst.

Aktuelle Cipher-Suite-Konfiguration prüfen, etwa mit openssl ciphers -v oder dem entsprechenden Server-Befehl.
Zielhardware bewerten: Steht AES-NI auf dem Server zur Verfügung, bleibt AES-256-GCM an erster Stelle sinnvoll.
Beide Suiten in der Konfiguration aktiv halten, damit Clients ohne AES-Beschleunigung automatisch ChaCha20-Poly1305 erhalten.
Reihenfolge in der Serverkonfiguration anpassen, sodass der Server die Präferenz des Clients respektiert statt sie zu überschreiben.
Nach der Änderung mit einem TLS-Scanner die tatsächlich ausgehandelten Suiten in der Praxis kontrollieren.
Für SSH-Verbindungen zu älteren Embedded-Geräten [email protected] gezielt priorisieren.
Änderungen zunächst in einer Staging-Umgebung testen und erst nach erfolgreicher Verbindungsprüfung auf die Produktionsserver ausrollen.
Einen Rollback-Plan bereithalten, falls ältere Clients mit der neuen Cipher-Suite-Reihenfolge nicht zurechtkommen.

Ein häufiger Stolperstein bei der Migration ist die Annahme, ein Wechsel der Cipher-Suite-Reihenfolge würde bestehende Verbindungen sofort umstellen. In der Praxis gilt die neue Konfiguration erst für neu aufgebaute TLS- oder SSH-Sitzungen, bestehende Sitzungen laufen mit der ursprünglich ausgehandelten Suite bis zum natürlichen Verbindungsende weiter. Wer die Umstellung überwachen will, sollte deshalb vor und nach der Änderung die tatsächlich genutzten Cipher-Suiten in den Server-Logs vergleichen, statt sich allein auf die Konfigurationsdatei zu verlassen.

# Nginx: beide Cipher-Suiten aktiv halten, Client-Präferenz respektieren
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;
ssl_prefer_server_ciphers off;

# OpenSSH: ChaCha20 fuer Geraete ohne AES-NI priorisieren
# /etc/ssh/sshd_config
Ciphers [email protected],[email protected]

Die Zeile ssl_prefer_server_ciphers off ist hier der eigentliche Trick: Sie überlässt dem Client die Wahl, sodass ein Smartphone ohne AES-Hardware automatisch ChaCha20-Poly1305 bekommt, während ein Server-zu-Server-Request zwischen zwei Xeon-Maschinen bei AES-256-GCM bleibt. Diese doppelte Konfiguration ist in TLS 1.3 Standardpraxis und erfordert keine zusätzliche Bibliothek.

Ein zweiter, oft übersehener Punkt bei der Migration betrifft Monitoring und Logging. Sicherheitsteams sollten vor der Umstellung festlegen, welche Cipher-Suite in den Zugriffs- und Verbindungsprotokollen auftaucht, damit eine spätere Analyse nachvollziehen kann, welcher Anteil des Traffics tatsächlich auf AES-256-GCM und welcher auf ChaCha20-Poly1305 entfällt. Diese Daten helfen auch dabei, die Serverkapazität realistisch zu planen, denn ein höherer ChaCha20-Anteil unter mobilen Nutzern wirkt sich anders auf die CPU-Last aus als ein überwiegend AES-basierter Desktop-Traffic.

Das Urteil: Wer gewinnt den Vergleich 2026

Es gibt keinen einzelnen Gewinner, die Daten zeigen stattdessen zwei klar getrennte Einsatzgebiete. Auf Server-Hardware mit AES-NI liegt AES-256-GCM mit rund 4.200 zu 3.800 MB/s etwa zehn Prozent vorn, ein Vorsprung, der sich bei hohem Traffic-Volumen direkt in Serverkosten übersetzt. Sobald die Hardware-Beschleunigung fehlt, kehrt sich das Verhältnis drastisch um: ChaCha20-Poly1305 erreicht in mehreren unabhängigen Tests drei- bis vierfache Geschwindigkeit gegenüber Software-AES, teils sogar das Zehnfache bei absoluten MB/s-Werten auf schwacher Hardware.

Für Betreiber großer Server-Flotten mit moderner Hardware bleibt AES-256-GCM die wirtschaftlich sinnvollere Standardeinstellung. Für Entwickler mobiler Apps, IoT-Produkte und VPN-Software, die eine breite und oft ältere Gerätebasis bedienen müssen, ist ChaCha20-Poly1305 die robustere Entscheidung, nicht aus Sicherheitsgründen, sondern aus reiner Performance- und Energiebilanz. Die gute Nachricht für alle, die sich nicht entscheiden wollen: TLS 1.3 und OpenSSH erlauben, beide Optionen gleichzeitig anzubieten und die Wahl pro Verbindung dem jeweiligen Client zu überlassen.

Kurz zusammengefasst: Wer vor allem Server mit aktueller x86- oder ARM-Server-Hardware betreibt, sollte AES-256-GCM an die erste Stelle der Cipher-Suite-Liste setzen. Wer Software für ein breites, oft älteres Gerätespektrum entwickelt, von Billig-Smartphones bis zu IoT-Sensoren, profitiert von ChaCha20-Poly1305 als primärer oder zumindest gleichwertiger Option. Die sicherste strategische Entscheidung für 2026 besteht nicht darin, sich für immer auf einen der beiden Algorithmen festzulegen, sondern die eigene Infrastruktur so zu konfigurieren, dass sie beide Optionen situationsgerecht ausspielt.

Häufige Fragen zu AES-256 und ChaCha20

Ist ChaCha20 sicherer als AES-256?

Beide gelten als sicher gegen praktische Angriffe auf die volle Schlüssellänge. ChaCha20 ist durch seine Bauweise von Natur aus resistenter gegen bestimmte Cache-Timing-Seitenkanäle, während AES-256 bei korrekter Hardware-Implementierung ebenfalls keine praktischen Schwachstellen aufweist. Der Sicherheitsunterschied in der Praxis ist gering, solange die Nonce-Verwaltung bei beiden korrekt umgesetzt ist.

Warum nutzt WireGuard nur ChaCha20 und kein AES?

WireGuard soll auf möglichst vielen Geräten gleich schnell laufen, von leistungsstarken Servern bis zu kleinen Routern ohne AES-Beschleunigung. ChaCha20-Poly1305 liefert diese gleichmäßige Performance ohne Rücksicht auf die vorhandene Hardware, deshalb verzichten die Entwickler bewusst auf eine AES-Option.

Welche Cipher-Suite wählt mein Browser automatisch?

Browser und Server handeln die Cipher-Suite bei jedem TLS-1.3-Verbindungsaufbau neu aus. Je nach Serverkonfiguration und Geräte-Hardware kann das TLS_AES_256_GCM_SHA384 oder TLS_CHACHA20_POLY1305_SHA256 sein. Nutzer bekommen davon in der Regel nichts zu sehen, die Aushandlung läuft automatisch im Hintergrund.

Lohnt sich AES-256 noch auf älteren Smartphones?

Auf Geräten ohne AES-Hardwarebeschleunigung fällt der Durchsatz von AES-256-GCM in Benchmarks auf 200 bis 500 MB/s, während ChaCha20-Poly1305 auf vergleichbarer Hardware deutlich höhere Werte erreicht. Für ältere oder günstigere Smartphones ist ChaCha20-Poly1305 deshalb häufig die bessere Wahl für Akkulaufzeit und Performance.

Was kostet die Schlüsselverwaltung für AES-256 in der Cloud?

AWS KMS berechnet etwa 1,00 US-Dollar pro Schlüssel und Monat plus Kosten für API-Anfragen oberhalb eines Freikontingents von 20.000 Anfragen. Google Cloud KMS berechnet kryptografische Vorgänge mit etwa 0,03 US-Dollar pro 10.000 Operationen, zusätzlich zu einer monatlichen Gebühr pro aktiver Schlüsselversion. Die genauen Kosten hängen vom Nutzungsvolumen und der gewählten Schutzklasse ab.

Kann ich AES-256 und ChaCha20 gleichzeitig anbieten?

Ja, das ist in TLS 1.3 und OpenSSH sogar Standardpraxis. Server können beide Cipher-Suiten aktivieren und die endgültige Wahl dem jeweiligen Client überlassen, der dann automatisch die für seine Hardware schnellere Option bevorzugt.

Welche Rolle spielt Poly1305 bei ChaCha20?

Poly1305 ist der Authentifizierungscode, der mit ChaCha20 zur AEAD-Suite ChaCha20-Poly1305 kombiniert wird. Er stellt sicher, dass verschlüsselte Daten nicht unbemerkt verändert werden können, ähnlich wie der GHASH-Mechanismus im GCM-Modus von AES.

Was ist der Unterschied zwischen AES-128 und AES-256?

AES-128 nutzt zehn Verschlüsselungsrunden und einen 128-Bit-Schlüssel, AES-256 verwendet vierzehn Runden und einen 256-Bit-Schlüssel. AES-128 ist dadurch geringfügig schneller, AES-256 bietet eine größere Sicherheitsmarge für die Zukunft. Da ChaCha20 praktisch immer mit 256-Bit-Schlüsseln läuft, ist AES-256 die passende Vergleichsbasis für diesen Artikel.

Unterstützt auch TLS 1.2 schon ChaCha20-Poly1305?

Ja, ChaCha20-Poly1305-Cipher-Suiten wurden bereits 2016 über RFC 7905 für TLS 1.2 nachgerüstet und sind seitdem in vielen Servern und Browsern verfügbar, die noch TLS 1.2 unterstützen. In TLS 1.3 gehört ChaCha20-Poly1305 von Anfang an zum Standardumfang der verhandelbaren Cipher-Suiten.