AES-GCM oder ChaCha20-Poly1305: die Datenchiffre für ein VPN wählen

Beide Namen sind AEAD-Konstruktionen, beide sind standardisiert, und auf einem aktuellen x86-Server sättigt jede von beiden eine Gigabit-Leitung ohne sichtbare Mühe. Die Wahl wird erst willkürlich, wenn Sie diesen Server verlassen: billige Router, ältere Telefone und virtuelle Appliances haben oft keine AES-Beschleunigung, und dort ist der Unterschied groß. Die Frage lautet also nicht, welche Chiffre schneller ist, sondern welche Chiffre dieses Endpunkt-Set gut ausführt und ob das Protokoll überhaupt eine Wahl bietet.

Gleiche Aufgabe, andere Kerne

Beide Konstruktionen liefern Vertraulichkeit und Integrität in einem Durchgang und authentifizieren zugehörige Daten, weshalb VPN-Protokolle sie für den Datenkanal verwenden. Der Unterschied liegt innen: AES-GCM ist die AES-Blockchiffre im Zählermodus mit einem polynomiellen Authenticator über GF(2^128), während ChaCha20-Poly1305 eine Stromchiffre mit 256-Bit-Schlüssel und einem separaten Einmal-Authenticator ist.

Was operativ zählt, ist gemeinsam: Beide versagen katastrophal bei Nonce-Wiederverwendung, beide brauchen eine Nonce-Verwaltung pro Schlüssel, und keines repariert einen Peer, der das Falsche authentifiziert. Ein Profil mit AES-256-GCM ist nicht sicherer als eines mit CHACHA20-POLY1305; beide sind stark, wenn die Implementierung korrekt ist.

Wo AES-GCM gewinnt

AES hat auf den meisten modernen CPUs dedizierte Instruktionen: AES-NI auf x86, die Krypto-Erweiterungen auf ARMv8 und Äquivalente auf neueren POWER- und RISC-V-Designs. Sind sie vorhanden, führt GCM mehrere Blöcke parallel pro Zyklusklasse aus, und die Software-Implementierung ist irrelevant. Das ist der Normalfall für Server, Desktops und aktuelle Telefone, und deshalb ist der Rat, AES zu verwenden, im Rechenzentrum eine vernünftige Voreinstellung.

Das Problem ist der Fall zweiter Ordnung. Ohne dedizierte Instruktionen ist AES in Software langsam, und tabellengesteuerte Software-Implementierungen sind die mit der langen Geschichte von Cache-Timing-Problemen. Ein VPN-Konzentrator in einer virtuellen Maschine, deren Host dem Gast keine AES-Flags zeigt, ist genau dieser Fall, und er wird leicht übersehen, weil die Host-CPU die Funktion hat.

Prüfen Sie, was der Prozess tatsächlich sieht, nicht was die CPU unterstützt: grep -o aes /proc/cpuinfo | head -1 unter Linux oder das entsprechende Funktionsflag im CPU-Modell des Hypervisors.

Wo ChaCha20-Poly1305 gewinnt

ChaCha20 ist in portabler Software schnell, weil es nur Addition, Rotation und XOR nutzt, und seine Implementierungen vermeiden geheimnisabhängige Tabellenzugriffe von der Konstruktion her. Auf einem Gerät ohne AES-Beschleunigung ist das ein materieller Vorteil, und genau deshalb hat WireGuard es gewählt: die Protokollbeschreibung von WireGuard nennt ChaCha20-Poly1305 als Datenchiffre ohne Alternative.

Diese eine Entscheidung sagt etwas Nützliches: Auf Hardware mit AES-Beschleunigung gibt WireGuard etwas Durchsatz gegenüber AES-GCM auf, und die Autoren haben das für vorhersehbares Verhalten über Telefone, Heimrouter und Container-Hosts hinweg akzeptiert. Wenn Ihr Bestand überwiegend aus kleinen ARM-Boxen besteht, fällt dieser Tausch zu Ihren Gunsten aus.

Der Gegenfall ist ein ausgelasteter x86-Konzentrator, wo AES-GCM mit AES-NI der schnellere und besser unterstützte Weg ist und ChaCha20 messbare CPU pro Gigabit kostet. Keine der beiden Konstruktionen ist eine Schwäche; die Frage ist, welche Ihre Hardware billig ausführt.

Was Ihr Protokoll Sie tatsächlich wählen lässt

Beachten Sie die Trennung in OpenVPN: Steuerkanal und Datenkanal werden getrennt ausgehandelt, die Suite, die Sie für TLS sehen, sagt also nichts über die Chiffre, die Ihre Nutzlast schützt. Die Sitzungszusammenfassung meldet beides, und nur eines von beiden zu lesen ist eine häufige Verwechslungsquelle.

In OpenVPN kommt die Datenkanal-Chiffre aus der Liste data-ciphers auf beiden Seiten. Wenn sich die Liste des Servers und die des Clients nicht überschneiden, fällt die Verbindung entweder auf das zurück, was data-ciphers-fallback erlaubt, oder sie scheitert ganz, und dieses Scheitern wird meist der falschen Schicht angelastet. Setzen Sie dieselbe Liste auf beiden Seiten und bestätigen Sie das ausgehandelte Ergebnis im Log, statt anzunehmen, die Reihenfolge der Liste sei beachtet worden.

Entscheiden Sie anhand von drei Fakten zur Bereitstellung

Erstens: Haben die Endpunkte AES-Beschleunigung? Wenn jeder Peer sie hat, ist AES-GCM die billigere Wahl und der Standard in den meisten gepflegten Konfigurationen. Wenn ein relevanter Anteil kleine Router oder ältere Telefone sind, hält ChaCha20-Poly1305 den Rest des Bestands davon ab, zum Kapazitätslimit zu werden.

Zweitens: Bietet das Protokoll überhaupt eine Wahl? Bei WireGuard wurde die Entscheidung für Sie getroffen, und die nützliche Arbeit besteht darin, zu prüfen, dass das Werkzeug drumherum nicht still etwas anderes einsetzt. Bei OpenVPN und IPsec ist die Antwort eine Konfigurationszeile und ein aufgezeichnetes Aushandlungsergebnis.

Drittens: Können sich beide Seiten einigen? Eine Chiffre, die ein Peer nicht implementiert, ist keine Performance-Entscheidung, sondern ein Ausfall. Deshalb zählt die Peer-Liste mehr als jeder Benchmark: Ein gemischter Bestand braucht die Schnittmenge der Fähigkeiten, nicht die Vorliebe der schnellsten Maschine.

Wenn Sie messen, halten Sie Gerät, Endpunkt und Last identisch und ändern Sie eine Sache. Ein Test, der zwei Server in verschiedenen Regionen vergleicht, misst die Route, nicht die Chiffre, und ein Laptop-Benchmark sagt nichts über einen Container-Host, dessen CPU-Flags maskiert sind. Vergleichen Sie, und schreiben Sie auf, welche Chiffre tatsächlich ausgehandelt wurde: Diese Aufzeichnung ist mehr wert als der Benchmark.