Der Mythos über "mobile" CHACHA20

Bei der Vorbereitung der Methodik zur Berechnung des HTTPS-Zuverlässigkeitsindex haben wir eine Menge thematischer Literatur durchgesehen und mehr als einmal eine Empfehlung zur Unterstützung von Cipher Suites gefunden, die auf dem CHACHA20-Verschlüsselungsalgorithmus auf einem Webserver basieren, um die Belastung mobiler Clients zu verringern das kann keine Hardware AES verwenden. In diesem Zusammenhang wurden in der Regel Mediatek-Prozessoren und "Old Budget Mobile-Prozessoren" genannt.



Hält CHACHA20 mit seinem vertrauenswürdigen Begleiter POLY1305 mobile Clients wirklich kühl und lohnt es sich, es auf einem Webserver zu unterstützen? Lass es uns diskutieren!



CHACHA20 wurde von dem bekannten Kryptographen Daniel Bernstein erstellt, den wir besonders für seine Curve25519 lieben, und für seine Lobbyarbeit, bei der sich nur Oldfags daran erinnern, wofür _EXPORT_ in einer Chiffresuite stand. Der Algorithmus ist gut erforscht, arbeitet im AEAD-Modus, hat keine bekannten Schwachstellen oder Schwachstellen und ist einer von zwei Verschlüsselungsalgorithmen, die von der IETF für die Verwendung in TLS 1.3 genehmigt wurden (der andere ist unsterbliches AES).



Die theoretische kryptografische Stärke bei Verwendung in TLS wird im Intervall zwischen AES-128 und AES-256 im GCM-Modus unterschiedlich geschätzt, was nach heutigen Standards und auf absehbare Zeit als ausreichend angesehen wird. Gleichzeitig wird darauf hingewiesendass CHACHA20 "schneller" als AES ist, d.h. "Verbraucht weniger Prozessorressourcen, um die gleiche kryptografische Stärke bereitzustellen." Diese Formulierung riecht nicht nur nach Telemarketing (bei allem Respekt vor dem Autor), sondern übersieht auch ein wichtiges Detail: auf Prozessoren ohne Hardware-AES-Unterstützung.



Und hier kehren wir endlich zu "Budget Mobile Processors" zurück, die unter AES überhitzen, zu drosseln beginnen und flüssigen Stickstoff (Sarkasmus) fordern. Prozessorhersteller sind sich des Problems bewusst und haben es durch Hinzufügen einer entsprechenden Anleitung gelöst. In x86-kompatiblen Prozessoren ist dies AES-NI, in anderen - ihren Namen (und ihrem eigenen Satz). Und hier kommen wir zum interessantesten Teil: AES-Unterstützung durch Prozessoren.



Intel hat 2010 die Unterstützung für AES-NI in Westmere-Prozessoren eingeführt, und nicht in allen: Atom, Celeron, Pentium und Core i3, auf die es sich seit langem nicht mehr verlassen hat. Sie können sicher sein, dass AES-NI unterstützt wird, ohne sich erst ab der Goldmont-Architektur (Apollo Lake und Denverton) mit den Spezifikationen zu befassen. Dies ist bereits 2016.



Für AMD sind dies die Architekturen Bulldozer (2011) und Jaguar (2013), bei ARM ist alles komplizierter: Unterstützung für AES-Anweisungen wird in der ARMv8-A-Architektur bereitgestellt (2011, das erste Gerät ist 2013), aber die tatsächliche Implementierung von ihnen in Silizium hängt vom Hersteller Prozessor ab und ich persönlich würde nicht so sicher über "Old Budget Mobile Prozessoren" pfeifen, sondern es lohnt sich über "Nicht-Flaggschiff Mobile Prozessoren" im Allgemeinen zu sprechen, inkl. bis heute produziert.



Einfach ausgedrückt ist es nicht so schwer, auf einen Prozessor ohne AES-Hardwareunterstützung zu stoßen. CHACHA20 ist also wirklich eine großartige Alternative zu AES? Schauen wir uns zum Beispiel die Ergebnisse dieser Studie an . Auf Prozessoren ohne AES-Unterstützung ist CHACHA20 in der Leistung oftmals deutlich voraus. Leider wurden uns keine Temperaturmessungen angezeigt, aber wenn es sich um einen Serverprozessor handelt, ist es offensichtlich, dass der Unterschied in den verbrauchten Prozessorressourcen erheblich ist.



Bei AES-fähigen Prozessoren ist die Situation umgekehrt. Es lohnt sich kaum, CHACHA20 dafür verantwortlich zu machen, dem niemand einen persönlichen Befehlssatz im Prozessor angeboten hat, und was passiert, wenn beide Spieler nach denselben Regeln spielen, die wir auf alten Prozessoren gesehen haben (daran erinnern: AES verschmilzt).



Lassen Sie uns also die CHACHA20-Unterstützung auf Webservern in Anspruch nehmen. Warum nicht, wenn auch nur aus dem Grund, dass nicht alle Eier in einen Korb gelegt werden und wenn morgen plötzlich ein Loch in AES selbst oder dessen Implementierung in einer bestimmten Kryptobibliothek gefunden wird, können wir es "bis zur Klärung" mit einer geringfügigen Deaktivierung ausschalten Bewegung unserer Hand, auf CHACHA20 bleiben und nicht verzweifelt nach etwas suchen, das AES ersetzt, sondern wie es sich einschaltet.



Die Frage nach dem Platz von CHACHA20 in unserem Leben ist viel weniger einfach. die Liste der vom Webserver zur Verhandlung angebotenen Chiffresuiten, dh ihre Priorität.



Denken Sie daran, wie die Verschlüsselungssuite beim Herstellen einer HTTPS-Verbindung im Allgemeinen ausgehandelt wird: Der Client sendet die Liste der unterstützten Verschlüsselungssuiten an den Server in der Reihenfolge "vom Bulldozer". Diese Reihenfolge kann nur über Windows-Gruppenrichtlinien und nur für geändert werden Internet Explorer- Browser, die SChannel verwenden (richtig, wenn ich falsch liege). Der Server vergleicht die vom Client empfangene Liste mit der Liste der von ihm unterstützten Cipher Suites und teilt dem Client mit, welche zum Sichern der Verbindung ausgewählt wurde. Wenn die Priorität von Cipher Suites auf dem Server festgelegt ist, wird die erste, die in beiden Listen übereinstimmt, unter Berücksichtigung der auf dem Server festgelegten Priorität vereinbart. Wenn nicht eingestellt, dann Der Serveradministrator muss sich die Hände abreißen, wir tauchen in das Feld der unbekannten Wahrscheinlichkeitstheorie ein.



Die Priorität von Cipher Suites auf dem Server wird normalerweise auf der Grundlage des Prinzips der maximal verfügbaren Sicherheit festgelegt: Die stärkeren Cipher Suites werden zuerst aufgeführt, weniger - zuletzt. Ein moderner Client stößt auf eine starke Verschlüsselungssuite und stimmt dieser zu. Ein "veralteter" Client springt weiter unten in der Liste zu einer weniger starken Verschlüsselungssuite und stimmt dieser zu. Jeder ist glücklich, alles funktioniert, von jedem nach seinen Fähigkeiten bis zu jedem, der HTTPS verwendet.



Und hier passt eine auf CHACHA20 basierende Cipher Suite in dieses harmonische Bild der Welt, das wir hinzufügen, um die Belastung der Clients aus Hardware-Sicht zu verringern, ohne zu wissen, ob sie gleichzeitig "veraltet" oder "veraltet" sind nicht (dh das diesjährige Flaggschiff eines dritten chinesischen Unternehmens oder ein mittelständischer Fünfjähriger einer erstklassigen Marke). Der Kunde weist darauf hin, dass TLS 1.3 und eine vollständige Suite der zugehörigen Cipher Suites, sowohl AES als auch CHACHA20, unterstützt werden. Ihre Lösung, Administrator, welche Verschlüsselungssuite stimmen wir dem Kunden zu? Hier bin ich ungefähr gleich ... Ich



fasse das Obige über den CHACHA20-Verschlüsselungsalgorithmus zusammen.

1. Der Algorithmus ist ziemlich gut für sich und eignet sich für die Verwendung in TLS.
2. Darauf basierende Cipher Suites werden nur von relativ modernen Browsern unterstützt , sodass AES überhaupt nicht benötigt wird.
3. Der Leistungsgewinn durch seine Verwendung kann nicht nur auf "mobilen Budgetprozessoren mit altem Budget" erzielt werden, sondern auch auf Desktops und Servern. Auf Prozessoren mit Hardware-AES-Unterstützung ist die Situation umgekehrt.
4. Beim Herstellen einer HTTPS-Verbindung kann nicht festgestellt werden, ob der Prozessor des Clients AES in der Hardware unterstützt. Dementsprechend gibt es keine Möglichkeit zu wissen, welche Verschlüsselungssuite jeweils "schneller" sein wird.