Welche Schlüsselgröße verwendet das Tool?

Die, die Ihre Schlüssellänge angibt. 32 Hexadezimalzeichen sind 16 Byte, 48 sind 24, 64 sind 32, so dass die drei legalen Längen AES-128, AES-192 und AES-256 wählen, und die Rundenzahl folgt mit 10, 12 und 14. Das Tool akzeptiert jede gerade Hexadezimalzeichenfolge in diesem Bereich und lässt die Länge die Wahl treffen.

Warum werden meine 12 Byte Eingang 28 Byte verschlüsselt?

GCM hängt dem Chiffrat einen 16-Byte-Authentifizierungstag an, so werden 12 Byte Klartext bei jeder Schlüsselgröße 28 Byte Chiffrat, und diese 28 Byte werden als 40 base64-Zeichen gerendert. Der Tag ist kein Overhead, den man verwerfen kann — er ist es, was die Manipulationserkennung ermöglicht, und Entschlüsseln ohne ihn schlägt fehl.

Was passiert, wenn ich denselben IV mit demselben Schlüssel wiederverwende?

Das Tool zeigt eine Warnung, denn das ist der Fehler, der GCM bricht. Denselben Schlüssel mit demselben IV wiederverwenden bedeutet denselben Zähler-Schlüsselstrom in beiden Läufen, und die zweite Nachricht gibt dann dem Angreifer, was nötig ist, um die erste abzubröseln. Das Tool merkt sich jedes Schlüssel-IV-Paar, das es in der Sitzung schon benutzt hat, und markiert es, sobald Sie versuchen, mit einem von ihnen erneut zu verschlüsseln. Erzeugen Sie für jede Nachricht einen neuen IV — und idealerweise einen neuen Schlüssel.

Wie weiß ich, dass das Chiffrat nicht manipuliert wurde?

Die Entschlüsselungseite prüft den 16-Byte-Tag, bevor sie etwas zurückgibt, und ein invertiertes Bit irgendwo im Chiffrat lässt die Prüfung scheitern, so dass das Tool einen Entschlüsselungsfehler anzeigt, statt stillen falschen Text zurückzugeben. Das ist der ganze Punkt von GCM gegenüber reinem Zählermodus: Die Ausgabe verifiziert, oder sie kommt überhaupt nicht zurück.

Werden meine Daten an einen Server gesendet?

Nein. Die Verschlüsselung, die Tag-Prüfung und die base64-Kodierung laufen alle im Browser über Web Crypto und Web-APIs auf dem lokalen Gerät. Schlüssel, IV und Text verlassen es nie, und genau das macht das Tool für Text nutzbar, den Sie nicht in ein Formular kleben würden.

AES-Verschlüsselung/Entschlüsselung: 12 Byte in 28 mit AES-GCM Verschlüsseln — das 16-Byte-Tag, der 12-Byte-IV und die Wiederverwendungs-Warnung

Text im Browser zu verschlüsseln ist eine Hin-und-Rückfahrt mit Wache: Der Klartext wird mit einem Schlüssel in Chiffrat verwandelt, und ein 16-Byte-Authentifizierungstag wird angehängt, so dass jeder, der auch nur ein Bit des Chiffrats unterwegs ändert, auffällt. AES-Verschlüsselung/Entschlüsselung fährt diese Hin-und-Rückfahrt vollständig im Browser mit AES-GCM: 12 Byte Klartext werden 28 Byte Chiffrat, ein Hexadezimalschlüssel mit 32, 48 oder 64 Zeichen wählt AES-128, 192 oder 256, und der 24-Zeichen-IV hat 12 Byte. Die Ausgabe ist base64 — 40 Zeichen für dieses 12-Byte-Beispiel — und die Entschlüsselungseite lehnt ab, was manipuliert wurde. Nichts verlässt die Maschine.

Was GCM zum Blockchiffren hinzufügt

AES allein ist ein Blockchiffre: Es nimmt 16 Byte auf einmal und vermischt sie durch eine feste Anzahl Runden — 10 für einen 128-Bit-Schlüssel, 12 für 192, 14 für 256. Ein Blockchiffre allein versteckt die Länge der Nachricht nicht, akzeptiert keine Nachricht, die kein Vielfaches von 16 Byte ist, und sagt nicht, ob das Chiffrat unterwegs geändert wurde. GCM fügt drei Dinge hinzu: Es lässt den Chiffre in Modus Zähler laufen, so dass eine Nachricht beliebiger Länge fließt; es leitet einen Schlüsselstrom ab, der mit dem Klartext XORiert wird, das ist es, was den Inhalt verbirgt; und es berechnet einen 16-Byte-Authentifizierungstag über das Chiffrat mit einem geschlüsselten Hash. Der Tag ist die Wache: Invertieren Sie ein Bit des Chiffrats, und die Entschlüsselungseite wirft einen Fehler, statt Müll zurückzugeben. Ein Hash-Generator berechnet Digests derselben Familie, aber ohne Schlüssel, für Integrität und Deduplizierung, und ein Digest lässt sich nicht umkehren, so kann reines Haschen niemals Verschlüsselung sein — der GCM-Tag nimmt die Hash-Idee und versieht sie mit einem Schlüssel, was sein Anhängen sicher macht.

Der Schlüssel, der IV und das Paar, das sich nicht wiederholen darf

Der Schlüssel ist das Material: 32 Hexadezimalzeichen sind 16 Byte, 48 sind 24, 64 sind 32, so dass die drei legalen Längen AES-128, AES-192 und AES-256 wählen, und der Schlüssel bleibt nach dem importKey in einem nicht extrahierbaren Handle innerhalb der Web Crypto, weder gespeichert noch gesendet. Der IV (Initialisierungsvektor) hat 24 Hexadezimalzeichen, 12 Byte, und muss sich von jedem anderen IV unterscheiden, der mit demselben Schlüssel verwendet wurde. Das ist das Paar, das sich nicht wiederholen darf: derselbe Schlüssel mit demselben IV zweimal ist der Fehler, der GCM bricht, denn der Zähler-Schlüsselstrom wäre in beiden Läufen identisch, und die zweite Nachricht gäbe dem Angreifer die Fähigkeit, die erste abzubröseln. Das Tool merkt sich die in der Sitzung bereits benutzten Schlüssel-IV-Paare und zeigt eine Warnung an, sobald Sie versuchen, mit einem von ihnen erneut zu verschlüsseln. Zum Vergleich nutzt ein HMAC-Generator dieselbe Art geschlüsselten Hashes für die umgekehrte Arbeit: Er authentifiziert eine Nachricht, ohne sie zu verstecken, so dass HMAC antwortet, ob der Inhalt unverändert und von Ihnen ist, während GCM das und ob er zudem geheim ist, antwortet.

Woher der Zufall kommt

Wenn die Seite lädt, füllt das Tool die beiden Felder für Sie: einen 64-Zeichen-Zufallshexadezimalschlüssel, 32 Byte, und einen 24-Zeichen-Zufalls-IV, 12 Byte, erzeugt über denselben getRandomValues-Weg der Web Crypto, der die Verschlüsselung trägt. Der Zufall ist es, was den IV einzig hält: Ein 12-Byte-Zufalls-IV hat eine vernachlässigbare Kollisionswahrscheinlichkeit über eine kleine Anzahl Nachrichten, und ein neuer Schlüssel eliminiert sogar das. Wenn Sie im selben Browser Bezeichner erzeugen, zieht der UUID-Generator aus derselben Zufallsquelle für UUIDs der Version 4, und dieselbe Vorsicht gilt: Zufall ist eine Lieferung, keine Einstellung, und der Browser ist der Ausgeber. Behandeln Sie die beiden erzeugten Felder wie ein Reisepass — sie gehen mit Ihnen und werden nicht geteilt.

Die base64-Ausgabe lesen

Das Chiffrat ist binär, so malt das Tool es in base64, die Kodierung, die jede Gruppe von drei Byte auf vier Zeichen abbildet. Deshalb kommt der 12-Byte-Klartext nicht als 12 Zeichen zurück: Die 28 Byte Chiffrat, die 12 plus der 16-Byte-Tag, kodieren sich in 40 base64-Zeichen, die letzte Gruppe absorbiert den Rest als Füllung. Das Wachstum ist stabil: 100 Byte Klartext ergeben 116 Byte Chiffrat, das sind 156 base64-Zeichen, und 1000 Byte ergeben 1016, das sind 1356 Zeichen. Die zusätzlichen 16 Byte sind jedes Mal derselbe Tag, so ist der Overhead bei langen Nachrichten vernachlässigbar und bei kurzen sichtbar. Wenn Sie die Byte an eine Stelle weitergeben müssen, die die rohe Kodierung erwartet, wandelt der Base64-Encoder/-Decoder zwischen der Textform und den anderen Darstellungen um, ohne den Inhalt anzufassen.

Der Schlüssel ist das ganze System

AES-GCM ist nur so stark wie der Schlüssel dahinter, und ein Schlüssel ist ein Geheimnis im selben Sinne wie ein Passwort: Seine Stärke ist eine Funktion von Länge und Unvorhersehbarkeit, und seine Verwaltung besteht darin, ihn nicht zu wiederholen und nicht dort aufzuschreiben, wo jeder ihn lesen kann. Das Tool urteilt nicht über Ihren Schlüssel — es akzeptiert jede gerade Hexadezimalzeichenfolge zwischen 32 und 64 —, aber der ehrliche Check ist der, den ein Passwort-Stärke-Prüfer auf Passwörter anwendet, übersetzt ins Hexadezimale: Eine 64-Zeichen-Zeichenfolge, die ein wiederholtes Muster ist, ist 32 Byte Material und weit weniger als 256 Bits Entropie. Wenn Sie echtes Schlüsselmaterial statt eines eingegebenen brauchen, behandelt der Passwortgenerator-Führer dieselbe Disziplin der Erzeugung und Aufbewahrung, und ein zufälliger Hexadezimalschlüssel wird über denselben Ein-Klick-Weg erzeugt.

Wo AES außerhalb der Box auftritt

Dasselbe AES-GCM-Primitiv ist kein Browser-Spielzeug: TLS verwendet AES-GCM als eines seiner Kern-Chiffre der Aufzeichnungsebene, die Festplattenverschlüsselung auf modernen Betriebssystemen verwendet AES, gewöhnlich im XTS-Modus, und die Web-Crypto-API, die das Tool aufruft, ist dieselbe, die Bezahllaufzeitumgebungen, Anmeldungsabläufe und offline-first-Apps für den verschlüsselten lokalen Speicher aufrufen. Der Punkt dieses Tools ist, das Primitiv inspizierbar zu machen: Sie sehen das exakte Chiffrat, den exakten Tag-Overhead und den exakten Ausfallmodus der Manipulationserkennung, alles in einem Textfeld. Token sind die andere sichtbare Seite desselben Stacks — ein JWT-Dekoder öffnet Kopf und Nutzlast des Tokens, um zu zeigen, was signiert ist und was nicht, und das ist der nur-lesende Zwilling dessen, was Verschlüsselung in Schreibrichtung tut.