Ich habe mich gestern einmal gründlicher mit der Blockchiffre AES befaßt, weil ich deren Implementierung starten wollte.
Als ich 2022 die Stromchiffren RABBIT und DRAGON implementierte, hatte ich bereits die offizielle NIST-pdf zu AES. Damals hatte ich mich gegen eine AES-Implementierung entschieden. Dazu ist es auch gestern gekommen.
STROMCHIFFRE
Die Stromchiffren erzeugen kryptographisch einen zufälligen Datenstrom mit einer Länge von z.B. 2^68 Byte _pro Schlüssel_. Das ist etwa 295 Exa-Byte oder 10^(20,47)! Es handelt sich um einen Zufallszahlengenerator.
Diese Zufallszahlen können XOR-verknüpft werden mit einer zu verschlüsselnden Datei: . datei = datei ^ random; . datei ist nun verschlüsselt. . datei = datei ^ random; . datei ist nun entschlüsselt. Es kann zwischen verschlüsseltem und entschlüsseltem Zustand gewechselt werden, einfach indem jeweils genau die gleiche Operation durchgeführt wird!
BLOCKCHIFFRE
Die Blockchiffre AES verschlüsselt in einem Lauf nur 16 Byte. Die Daten aus 'datei' (16 Byte) werden ganz zu Anfang immer wieder neu zugeführt. Ebenso, wie immer wieder ein (neuer) Schlüssel gegeben werden muß [1].
AES muß wegen Entschlüsselung quasi verdoppelt werden. Zur Entschlüsselung arbeitet ein 'inverses AES'. Es muß von fast allem eine inverse Funktion vorhanden sein, auch inverse Tabellen. Auch für die Modi müssen inverse Versionen vorhanden sein (s.nachfolgend).
Ein großes Thema sind die Modi, die AES überhaupt erst fähig machen, um eine Datei verschlüsseln zu können: ECB, CBC, CFB, OFB, CTR, XTS, CCM, GCM, EAX, ... Diese gehören nicht zum Algorithmus, sondern sind zusätzlicher gehöriger Aufwand! Es gibt bessere und schlechtere Modi, manche sind 'viel besser', andere sind 'gefährlich'!
Es fällt sehr auf, daß AES /über den grünen Klee gelobt/ wird - auch die Performance! Das wird wohl ungefähr berechtigt sein - allerdings nur im Vergleich mit den anderen Blockchiffren. Stromchiffren sind Blockchiffren stark überlegen, hinsichtlich der Größe des Quellcodes (z.B. 80 statt 500 Zeilen), der Verarbeitungsgeschwindigkeit über alles, der Ressourcenschonung und der besseren Handhabung und Übersichtlichkeit.
Dem Netz kann entnommen werden, daß AES durch Optimierungen mehr als 30-fach beschleunigt werden konnte. Dabei wurden die AES-intel-Instruktionen nicht erwähnt. Es wurden u.a. viele statische Arrays angelegt, um dies zu erreichen. Erwähnt wird, daß weitere 8 Arrays mit je 1024 Byte angelegt werden können. Im Umkehrschluß ist erkennbar, daß ohne diese Optimierungen die Performance miserabel sein muß. Solch eine Ressourcen-Ballerei ist bei Stromchiffren nicht anzutreffen.
Blockchiffren haben wohl prinzipielle Vorteile gegenüber den Stromchiffren. Diese sind jedoch z.B. für mich völlig irrelevant, so daß fast nur Nachteile übrig bleiben. Es ist jedenfalls günstiger, Stromchiffren zu verwenden, die mit Schlüsseln hoher Entropie beschickt werden. Beispielsweise kürzere Zeichenfolgen einem Hash-Kommando sha256 vorzulegen.
[1] Es gibt die Überlegung, daß nicht immer der gleiche Schlüssel gegeben werden kann, weil dann bei gleichen 16-Byte-Blöcken aus der zu verschlüsselnden Datei die verschlüsselte Datei entsprechend gleiche Stücke enthielte! Ich könnte einen Schlüssel durch addieren von Zahlen 1..255 jeweils zu einem neuen Schlüssel machen.