8. Advanced Encryption Standard

Transkript

1 8. Advanced Encryption Standard von Maximilian Fischer Im Jahre 1997 rief das amerikanische National Institute of Standards and Technology, kurz NIST, einen Wettbewerb für einen neuen offenen Verschlüsselungsstandard ins Leben: Advanced Encryption Standard, kurz AES, sollte der offizielle Nachfolger des von 1976 stammenden und inzwischen veralteten und unsicher gewordenen DES (Data Encryption Standard) werden. Der Algorithmus sollte ein symmetrischer 128bit-Blockalgorithmus sein (die Daten werden in Blöcken zu je 128bit = 16Byte mit dem gleichen Schlüssel ver- und entschlüsselt) und die Schlüssellänge sollte 128, 192 und 256bit betragen. Auch sollte der Algorithmus nicht nur höchste Sicherheit, sondern auch sehr gute Performance sowohl bei Software- als auch bei Hardwareimplementierungen gewährleisten. Bis zur Abgabefrist im Sommer 1998 wurden 15 Vorschläge eingesandt. Nun begann die erste Runde; da der Wettbewerb öffentlich war, konnte jeder der Lust hatte, die Kandidaten auf Herz und Nieren prüfen. Viele bekannte Kryptologieexperten machten sich sogleich daran die Algorithmen zu analysieren. Es dauerte nicht lange und schon wurden erste Schwächen gefunden und manche Verfahren erbarmungslos geknackt (dazu gehörte auch der von der Telekom eingereichte MAGENTA-Algorithmus). Die erste Runde endete 1999 mit der Bekanntgabe der fünf besten Kandidaten für die Endausscheidung: MARS IBM RC6 RSA Laboratories (Ronald L. Rivest et al.) Rijndael Joan Daemen, Vincent Rijmen Serpent Ross Anderson, Eli Biham, Lars Knudsen Twofish Bruce Schneier et al. Während der zweiten Runde wurde noch einmal viel getestet und analysiert. Die Entscheidung war nicht einfach, da alle Algorithmen sich als sicher erwiesen, damit gewann die Performance als Kriterium an Bedeutung. Am 2. Oktober 2000 war schließlich der Entscheidungstag gekommen. Die NIST erklärte eine leicht modifizierte Variante des Rijndael, jetzt AES genannt, als Sieger des Wettbewerbs. Die Jury begründete ihre Entscheidung damit, dass Rijndael verhältnismäßig sicher, leicht implementierbar und schnell in Hard- und Softwareimplementierung sei. Sicherlich entsprach es nicht der üblichen Sicherheitspolitik in den USA, dass man auf einen ausländischen Algorithmus zurückgreift, jedoch überzeugt Rijndael insbesondere durch seine Einfachheit (die Referenz-Implementierung umfasst weniger als 500 Zeilen C-Code) und Performance. Der Algorithmus ist frei verfügbar und darf ohne Lizenzgebühren eingesetzt und implementiert werden. In den USA ist AES für staatliche Dokumente mit höchster Geheimhaltungsstufe zugelassen. 174

2 Funktionsweise: AES ist ein symmetrischer Algorithmus, der, im Gegensatz zu einem asymmetrischen Algorithmus wie z.b. RSA, den gleichen Schlüssel zum Ver- und Entschlüsseln benutzt. Desweiteren arbeitet AES als sogenannter Blockalgorithmus. Das heißt, dass die Daten zu Blöcken zusammengefasst werden. Bei AES ist die Blockgröße auf 128bit (16Byte) festgelegt, während die Blockgröße bei seinem Vorgänger Rijndael variabel ist. Bei einer Blockgröße von 16Byte hat ein Block, wenn man diesen als 2dim ensionales Feld auffasst, eine Abmessung von 4*4. Jede Zelle entspricht dann einem Byte. Ein Block sieht also folgendermaßen aus: Wie arbeitet nun AES? Das Grundprinzip sieht wie folgt aus: Ein Datenblock, State genannt, wird abhängig vom Schlüsselblock, Cipher genannt, verschlüsselt. Die Verschlüsselung wird, das ist das Besondere an AES, nicht nur einmal durchgeführt, sondern, je nach Schlüssellänge, 10 mal (128bit), 12 mal (192bit) oder 14 mal (256bit). Der Block durchläuft jetzt bei jeder Einzel-Verschlüsselung, round (Runde) genannt, mehrere Abschnitte: Subbytes ShiftRows MixColumn AddRoundKey Die letzte Runde (final round) unterscheidet sich von der vorhergehenden dadurch, dass MixColumn ausgelassen wird. Zusätzlich gibt es noch eine Art 0te Runde, initial round genannt. In ihr wird nur die Funktion AddRoundKey ausgeführt. Die Funktion AddRoundKey ist etwas Besonderes. Sie ist die einzige Funktion in AES, die vom Benutzerschlüssel abhängig ist. Sie führt zwischen dem State (Datenblock) und dem Cipher (Chiffrenblock) eine XOR-Verknüpfung durch. XOR ist ein Begriff aus der Logik. Es bedeutet soviel wie Entweder A oder B (aber nicht beide). Praktisch entspricht dies der Addition zweier Bits modulo 2 - ist die Summe eine gerade Zahl ergibt sich 0, ist sie ungerade 1. Dazu ein Schaubild: 175

3 1. Bit 2.Bit Ausgabebit Das Ergebnis ist also wahr, wenn genau ein Input wahr ist. Die XOR-Verknüpfung ist dabei assoziativ und kommutativ, d.h. die Reihenfolge der Ausführung ist egal. Eine weitere Eigenschaft der XOR-Verknüpfung ist, dass die zweimalige Anwendung der Operation wieder zum Anfangswert führt, d.h. sie ist selbstinvers. Deshalb wird sie auch gerne in der Kryptographie (dadurch kann beim Verschlüsseln die gleiche Funktion verwendet werden wie beim Entschlüsseln) und auch beim RAID-System eingesetzt. Hier ein Beispiel zur Selbstinversität: xor = und ein zweites mal xor = Eine weitere Besonderheit bei AES ist der Umstand, dass für jede Runde ein anderer Cipher benutzt wird, der aus dem vorhergehenden generiert wird. Die initial round (0te Runde, zählt eigentlich nicht zu den normalen 10/12/14 Runden) verwendet den ursprünglichen cipher, jede weitere Runde wird ein neuer verwendet, der aus dem vorherigen generiert wird. Diese cipher nennt man auch Rundenschlüssel. Der Rundenschlüssel ist genau 16Byte groß, damit er mit dem state in Beziehung gesetzt werden kann. Später gehen wir darauf eingehen, wie genau diese neuen cipher generiert werden. Wir merken uns vorerst, dass für jede Runde ein neuer cipher generiert wird. Der expandierte Schlüssel muss in R + 1 Teilschlüssel (Rundenschlüssel) zerlegt werden können. Die Rundenschlüssel müssen die gleiche Länge wie die Blöcke erhalten (16Byte). Somit muss der Benutzerschlüssel auf die Länge b * (R + 1) expandiert werden, wobei b die Blockgröße angibt. Bei AES128 gibt es 10 Rundenschlüssel. Ein gegebenen Start-Schlüssel (Benutzerschlüssel) für AES128 ist 128bit (16Byte) lang und wird auf 16*(10+1) = 176Byte verlängert. Somit haben wir 11 Rundenschlüssel, wobei der erste Schlüssel nicht für eine Hauptrunde verwendet wird: die 10 Rundenschlüssel (bei der letzten Runden wird MixColumn ausgelasen) und eine Anfangsrunde (initial round). 176

4 Die anderen Typen von AES (AES192 und AES256) haben andere Rundenzahlen und somit andere Benutzerschlüssellängen, wie man auch am Namen erkennen kann. AES192 hat 12 Runden und der Benutzerschlüssel ist 192bit (24Byte) lang. Daraus ergibt sich nach b * (R + 1) ein 16*(12+1) = 208Byte langer erweiterter Schlüssel. AES256 schließlich hat 14 Runden und der Start-Schlüssel ist 256bit (32Byte) lang. Daraus ergibt sich ein 16*(14+1) = 240Byte langer expandierter Schlüssel. Noch ein Hinweis: Man kann nicht davon ausgehen, dass der Benutzerschlüssel multipliziert mit der Anzahl der Runden gleich die Länge des expandierten Schlüssels ist. Dies ist nur bei AES128 der Fall (16*(10+1) = 176), da dort die Blockgröße gleich der Schlüsselgröße ist; aber bei AES192 (24*(12+1) = 312) und AES256 (32*(14+1) = 480) stimmt dies nicht. Tatsächlich wird der Schlüssel bei AES128 volle 11mal erweitert, bei AES192 nur ~8,66-mal und bei AES256 sogar nur 7,5-mal. Das heißt AES256 ist am sichersten, da dort der eigentliche Benutzeranteil des Schlüssels größer ist. Beobachtungen; Der expandierte Schlüssel muss in R + 1 Teilschlüssel aufgeteilt werden können. Die Rundenschlüssel müssen die gleiche Länge wie die Blöcke erhalten. Somit muss der Benutzerschlüssel auf die Länge b * (R + 1) expandiert werden, wobei b die Blockgröße angibt. Der Benutzerschlüssel wird mit dem State-Block bitweise XOR verknüpft, bevor mit den Hauptrunden begonnen wird. Die FinalRound ist dieselbe Runde, wie die normalen Runden, nur mit der Ausnahme, dass die Operation MixColumn fehlt. Während jeder Runde, wird ein anderer Teil des expandierten Schlüssels für die Operationen verwendet. Als Grafik dargestellt sieht das folgendermaßen aus: 177

5 Die einzelnen Funktionen AddRoundKey Der State wird mit dem Cipher per XOR verknüpft. Beispiel: Wenn a(0,0) = 6E (hexadezimal) und k(0,0) = A3 dann ist b(0,0) = CD: (6E) xor (A3) = = CD So wird jede weitere Zelle mit der entsprechenden Zelle des cipher verknüpft: a(0,0) xor k(0,0) = b(0,0) a(0,1) xor k(0,1) = b(0,1) a(0,2) xor k(0,2) = b(0,2) a(0,3) xor k(0,3) = b(0,3) 178

6 a(1,0) xor k(1,0) = b(1,0) a(1,1) xor k(1,1) = b(1,1) a(1,2) xor k(1,2) = b(1,2).. Dieser Vorgang nochmals als Grafik: SubBytes Bei der Funktion SubBytes wird jedes Byte durch ein anderes Byte, das fest vorgegeben ist, ersetzt. Somit werden die Daten monoalphabetisch verschlüsselt. Dies dient dazu die Beziehung zwischen Klar- und Geheimtext zu verwischen. Die Verschlüsselung geschieht mit einer sogenannten Substitutionsbox, auch S-Box genannt. Das Ersetzen geschieht gemäß folgender Tabelle am Beispiel der hexadezimalen Zahl 19 (welche der 25 im Dezimalsystem entspricht): Noch ein paar Beispiele: Der erste Teil der zweistellig notierten Zahl (1) wird horizontal auf der Tabelle ausgewählt, der zweite Teil (9) vertikal. Daraus ergibt sich dann die Substitution: aus 19 wird D4. 179

7 D3 -> 66 7E -> F3 00 -> 63 FF -> 16 CC -> 4B 21 -> FD 0F -> 76 F0 -> 8C Zu der Tabelle sei erwähnt, dass dieser Vorgang in der praktische Umsetzung (programmieren) auch vereinfacht werden kann. Es besteht die Möglichkeit einen Array mit 256 Elementen anzulegen und dabei die neuen Werte nach Wertigkeit ihrer alten Substitutionspartner festzulegen, was vor allem den Zugriff erleichtert (Es gibt auch die Möglichkeit die Werte on-the-fly zu erzeugen). Beispiel: 00 hat den Wert 0. Sein Substitutionspartner steht deshalb an erster Stelle des Arrays mit Zugriff über den Index hat einen Dezimal-Wert von 25. Deshalb steht der Substitutionspartner von 19, D4, an 26ter Stelle (Ein Array fängt bei Null an) mit Zugriff über den Index 25. Dazu noch ein paar Beispiele: D3 hat einen Wert von 211. Sein Subsitutionspartner steht deshalb an der 212ten Stelle im Array. Das ist also 66. 7E hat einen Wert von 126. Ihr Subsitutionspartner steht deshalb an der 127ten Stelle im Array. Das ist also F3. 00 hat einen Wert von 0. Sein Subsitutionspartner steht deshalb an der 1ten Stelle im Array. Das ist also 63. (Diese Arrayreihenfolge erscheint zwar für einen Menschen undurchsichtiger, ein Computer kann damit jedoch besser arbeiten) Ein solcher Substitutions-Array könnte in der Implementierung dann etwa so aussehen: 180

8 Folgend ein Block vor und nach der Operation SubBytes: ShiftRows Die Funktion ShiftRows ist relativ einfach zu verstehen. Wie der Name schon andeutet, werden die Zeilen verschoben. Während die erste Zeile nicht verschoben wird, wird die Zweite um 1, die Dritte um 2 und die Vierte um 3 nach links verschoben. Überlaufende Zellen werden von rechts fortgesetzt. Dazu ein Beispiel: 181

9 MixColumn MixColumn ist nicht ganz so einfach. Sie beruht auf komplexen mathematischen Kalkulationen im Galois-Feld GF(2^8). Auf diese werden wir hier jedoch nicht genauer eingehen, was nicht zuletzt daran liegt, dass Berechnungen im Galois-Feld relativ komplex sind und daher üblicherweise erst im Mathematikstudium an der Uni durchgenommen werden. Folgend wollen wir also nur das Grundprinzip erläutern. Dieses sieht wie folgt aus: Jede Zelle einer Spalte wird mit einer Polynom- Konstanten multipliziert, wobei von der aktuelle Zeile ausgehend die Konstanten 02, 03, 01 und 01 lauten. Anschließend werden die Ergebnisse jeder Spalte per XOR verknüpft und in der entsprechenden Zelle des neuen Blocks gespeichert. Zu diesem relativ komplexen Sachverhalt ein Beispiel: (Quelle: Screenshot von [6] ) Wir beginnen mit der ersten Zelle (0,0) des neuen Blocks, welche, wie oben zu sehen, dann die Hexadezimalzahl 61 enthalten soll. Diese wird nun aus der ersten Spalte des alten Blocks berechnet: Je nachdem, welche Zelle wir in dem neuen Block füllen wollen, lautet die Polynom-Konstantenfolge anders: Sie beginnt mit der aktuelle zu füllenden Spalte und lautet für diese 02. Danach geht es abwärts weiter mit 03, 01 und 01. Zu unserem Bild: Wir sind dabei die erste Zelle zu füllen, also heißt die Konstante für die erste Zeile 02. Demnach wird 24 mit 02 multipliziert. Dies ist jedoch keine normale Multiplikation, sondern eine Polynom-Multiplikation im endlichen Galoisfeld, auf die wir hier nicht näher eingehen (für Interesierte gibt es den Quellcode später beim Implementieren). Aus der Polynom-Multiplikation von 24 und 02 ergibt sich 48 ( ). Danach werden 60 und 03, was A0 ( ) ergibt, 00 und 01, was 00 ( ) ergibt und 89 und 01, was 89 ( ) 182

10 ergibt, im GF multipliziert. Diese vier Ergebnisse (48, A0, 00, 89) werden per XOR verknüpft. Diese Verknüpfung ergibt dann 61 ( ). Das Ganze geht dann für diese Zeile so weiter: (Quelle: Screenshot von [6] ) Wenn wir nun in die nächste Zeile wechseln, ändert sich die Zuordnung der Polynom-Konstanten: Die erste Zeile hat nun 01, die Zweite 02, die Dritte 03 und die Vierte 01. Man könnte es so ausdrücken, dass mit jedem Zeilenwechsel die Polynom-Konstanten eins nach unten rutschen oder auch so, dass sie sich, ausgehend von der aktuelle Zeile, nach unten hin anordnen. Die nächste Zeile sieht dann also so aus (siehe Farbveränderung im linken Block): (Quelle: Screenshot von [6] ) 183

11 Key Schedule Der Key-Schedule dient dazu, aus dem Anwenderpasswort zuerst den Benutzerschlüssel und anschließend den für die Verschlüsselung benötigten erweiterten Schlüssel zu generieren, der dann in die Rundenschlüssel aufgeteilt wird. Um aus dem Passwort den Benutzerschlüssel zu generieren, wird meistens ein sogenannter Hash verwendet, allerdings ist dies von den AES-Spezifikationen nicht vorgeschrieben, so dass es einem freisteht, auf welche Art man aus dem Kennwort den Benutzerschlüssel generiert. Ein Hash ist gewissermaßen ein Fingerabdruck des Passwortes. So werden zum Beispiel Hashs auch beim Einloggen z.b. in ein Forum im Internet benutzt. Bei der Anmeldung wird der Hash des Passwortes in einer Datenbank gespeichert. Beim erneuten Einloggen wird wiederrum ein Hash des neu eingegebenen Passwortes generiert; wenn beide Hashs übereinstimmen, war das Passwort dasselbe. Die Verwendung von Hashs dient einerseits der zusätzlichen Sicherheit, weil somit Rückschlüsse auf das Originalkennwort schwerer sind und andererseits der Einfachheit, denn Hash-Werte haben eine konstante Länge z.b. 128bit, 192bit, 256bit, 320bit, 512bit. So muss der Anwenderschlüssel nicht erst in der Länge verändert werden. (Allerdings Als erstes wird aus dem Benutzerkennwort ein Hash mit der gewünschten Länge, also 128bit/192bit/256bit, erzeugt, welcher dann den Benutzerschlüssel darstellt: Beispiel bei AES128: Passwort: Hash: abcdefg bb17142a7a6b0407af81ee3410 Und im Blockformat: Aus diesem Start-Cipher werden jetzt die 10/12/14 Rundenschlüssel berechnet. Dieser Schritt wird KeyExpansion genannt. Die Funktion ExpandKey generiert jeweils aus dem vorherigen Cipherblock den neuen. Dies sieht folgendermaßen aus: 184

12 Nun zu den Details: Um aus einem Cipher den darauffolgenden zu generieren, werden folgende Operationen angewendet: RotWord SubBytes Rcon XOR-Verküpfungen (4mal) Die einzelnen Funktionen sind recht trivial: RotWord Die Funktion RotWord (für RotateWord) verschiebt die Spalte einfach um eins nach oben. So wird aus dem das hier: SubBytes 185

13 Die Funktion SubBytes kennen wir schon (siehe oben). Ein Wert wird durch sein Äquivalent in der S-Box ersetzt. Xor-Verküpfungen Diese kennen wir ebenfalls. XOR (exklusives Oder) entspricht einem entweder A oder B, aber nicht beide. Rcon Rcon ist eine interessante Neuerung. Rcon ist die stetige Potenz von x, also 02, zu einem benutzerspezifischen Wert. Die von Rcon zurückgegebene Spalte, Rcon[i], beinhaltet Werte die durch [x i-1, 00, 00, 00] gegeben sind, mit x i-1 als Anzahl der Exponenten von x (x als hexadezimaler Wert 02) im endlichen Galois-Feld(256). Alle Operationen bedienen sich der Arithmetik im Galois-Feld. Es erfolgt wiederum eine Modulo Reduktion mit dem unreduzierbaren Polynom m(x) = x 8 + x 4 + x 3 + x + 1. Zum Beispiel ist Rcon(1) = 1, das Rcon(2) = 2, das Rcon(3) = 4 und das Rcon(9) die hexadezimale Nummer 1b. Es gilt Rcon(i) = x(254+i). Im Prinzip reichen für 128-Bit Blöcke 10 Rcons aus, da der Rijndael bei dieser Blockgröße nicht mehr Rcons verwendet. Die Rcon Werte können, wie die S-Box-Werte, als statische Tabelle vorliegen, die mit i=1 beginnt oder on-the-fly, also zur Laufzeit berechnet werden, wobei die on-the-fly Berechnung vor allem bei Situationen eingesetzt wird, wo Speicherplatz gespart werden muss. Ein vollständiger Array mit den vorausberechneten Werten könnte in der Implementierung dann so aussehen: 186

14 Gesamter Ablauf des Key-Schedule Im Einzelnen gestaltete sich der gesamte Ablauf nun wie folgt: Je nach dem Typ von AES (AES128, AES192, AES256) gibt es horizontal 4/6/8 Spalten. Angefangen wird mit der ersten Spalte des neuen Blocks, die etwas aufwändiger berechnet wird als die darauffolgenden. Dazu wird die letzte Spalte des alten Blocks (aktuelle Spalte - 1 (Man denkt sich den erweiterten Cipher als horizontale Spaltenreihe)) mit der Funktion Rotword verändert. Danach wird jeder Wert der Spalte durch seinen entsprechenden Substitutionspartner ersetzt (SubBytes, siehe oben). Jetzt werden diese erzeugte Spalte und eine vorherige Spalte (aktuelle Spalte - 4) per XOR verknüpft. Die neu entstandene Spalte wird wiederum per XOR mit der Spalte verknüpft, die von der Funktion Rcon geliefert wird. Die daraus resultierende Spalte ist nun die erste Spalte des neuen Blocks. Die Berechnung der letzten Spalten des neuen Blocks geschieht einfacher. Sie resultieren aus einer XOR- Verknüpfung der vorherigen Spalte des neuen Blocks (aktuelle Spalte - 1) und einer vorherigen Spalte (aktuelle Spalte 4). Bei AES256 gibt es noch die Besonderheit, dass die mittlere Spalte eines Blocks (4 Spalte) per S-Box substituiert wird. Grafisch dargestellt sieht dies so aus (AES128): Die Orange Spalte ist eine vorherige Spalte (Wi-1) nach der RotWord- und SubBytes- Transformation. Grau ist die neue Spalte des ersten Blocks. 187

15 Folgend sieht man die Berechnung der weiteren Spalten durch eine einfache XOR-Verknüpfung der vorherigen Spalte des aktuellen Blocks (Wi-1) und der entsprechenden Spalte des alten Blocks (Wi-4): Nach Abschluss des Schlüsselerweiterns (Key-Expansion) sieht der erweiterte Cipher folgendermaßen aus: An der Seite erkennt man den vollständig erweiterten Schlüssel bei AES128: beginnend mit dem blauen Startcipher und danach die 10 weiteren Rundenschlüssel. 188

16 Zusammenfassung: AES ist eine Blockchiffre, das heißt die Daten werden blockweise verschlüsselt. Bei AES ist die Blockgröße mit 128-bit festgelegt, die Schlüssellänge kann 128, 192 oder 256 Bit betragen. Jeder Block wird zunächst in eine zweidimensionale Tabelle mit vier Zeilen und vier Spalten geschrieben, deren Zellen ein Byte groß sind. Jeder Block wird nun nacheinander bestimmten Transformationen unterzogen: SubBytes (Substitution per S-Box), ShiftRow (Zeilen verschieben), MixColumn (Operationen im GF(2 8 )) und AddKeyRound (XOR mit Rundenschlüssel). Aber anstatt jeden Block einmal mit dem Schlüssel zu verschlüsseln, wendet AES verschiedene Teile des erweiterten Originalschlüssels nacheinander auf den Klartext-Block an. Die Anzahl dieser Runden variiert und ist von der Schlüssellänge abhängig, bei AES128 beträgt sie 10 Runden, bei AES192 beträgt sie 12 Runden und bei AES256 beträgt sie 14 Runden. Entschlüsselung: Bisher haben wir immer nur vom Verschlüsseln gesprochen. Doch wie kommt man an die verschlüsselten Daten wieder heran? Im Prinzip wird der ganze Algorithmus rückwärts durchlaufen, es gibt jedoch ein paar kleine Unterschiede: Es muss eine andere Substitutionsbox (S-Box) benutzt werden, die sich aus Original-S-Box berechnen lässt und ebenfalls als konstanter Array schon fest im Programm integriert werden kann. Eine andere Kleinigkeit ist, dass die Verschiebung der Zeilen der Funktion ShiftRow (im nachfolgenden InvShiftRow für InvertShiftRow) in die andere Richtung erfolgt. Die Berechnung der Rundenschlüssel (KeyExpansion, Key Schedule) ist beim Ver- und Entschlüsseln genau gleich. Es wird einfach beim letzten Teilschlüssel angefangen. Hierzu die Entschlüsselung noch mal als Grafik (Vorsicht! Von unten nach oben lesen!): 189

17 Hier die andere S-Box zum Entschlüsseln als Beispielimplementation: 190

18 Soweit so gut. Nun geht es nach der grauen Theorie an den spaßigen Teil: Das Schreiben eines eigenen Programmes, das per AES ver-/entschlüsselt! Den AES-Algorithmus programmieren Ich bevorzuge hier die Bottom-up-Methode, da man die einzelnen Funktionen besser testen kann: Zuerst werden die einzelnen Funktionen und Klassen implementiert, um dann nach und nach zum fertigen Algorithmus zusammengesetzt zu werden. 1. Die Verschlüsselung Die Verschlüsselung ist der Hauptbestandteil des Algorithmus. Sie generiert aus dem Input und dem expandierten Schlüssel den verschlüsselten Output. Sie arbeitet Blockweise, das heißt sie bekommt einen 4*4 großen Array, wobei die Blockgröße folglich 16Byte ist. Fangen wird also mit den vier Grundbestandteilen an: 1.1. AddRoundKey: Was braucht AddRoundKey? Natürlich erst einmal den Datenblock und dann den erweiterten Schlüssel. Da AddRoundKey etwas zurückgeben soll, nämlich den verschlüsselten Block, implementieren wir sie als Funktion: TBlock ist dabei ein statischer, zweidimensionaler Array mit der Abmessung 4*4, also unser so oft erwähnter Block. Er ist dabei wie folgend definiert: i gibt die Zeilennummer an, j die Spaltennummer. Das einzige, eventuell auf den ersten Blick Merkwürdige, dürfte hier sein, dass cipherblock ebenfalls vom Typ TBlock ist, obwohl wir immer von dem erweiterten Schlüssel geredet haben. Wie wir jedoch weiter oben erfahren haben, ist der 191

19 expandierte Schlüssel nichts weiter als die 10+1Rundenschlüssel, welche ihrerseits eben auch nur Arrays der Größe 4*4, also vom Typ TBlock sind (Daher ist der expandierte Schlüssel auch als Array of TBlock implementiert, wie wir später sehen werden) SubBytes: Subbytes benötigt eine Substitutionstabelle, wie oben schon beschrieben: Raffinierterweise sind die Werte im Array so angeordnet, dass, wenn man einfach den Ausgangswert als Index übergibt, den entsprechenden substituierten Wert erhält (siehe weiter oben). Dies vereinfacht die Implementierung auf ein Minimum: Übergeben wird wieder ein einzelner Block, welcher dann substituiert zurückgegeben wird ShiftRows: 192

20 ShiftRows ist nun wirklich sehr einfach: Die Zeilen werden nach links geschoben, wie man ab dem zweiten Block abwärts erkennen kann MixColumn: Diese Funktion hat es wirklich in sich und ist sicherlich die komplizierteste in AES. Dies liegt nicht zuletzt daran, dass Berechnungen im Galoisfeld GF(2^8) durchgeführt werden, welches, wie bereits erwähnt, üblicherweise erst im Mathematikstudium an der Uni durchgenommen werden. Der Hauptteil ist noch relativ einfach: 193

21 Die einzelnen Zellen einer Zeile werden mit entsprechenden Polynomen durch die Funktion gf_mul im Galois-Feld GF(2^8) multipliziert und dann per XOR verknüpft. Die Funktion gf_mul ist dabei ungleich komplizierter: 194

22 ************************ Nun haben wir die vier Grundfunktionen und können uns daran machen, uns daraus eine Funktion zu basteln, die uns aus einem Eingabeblock und dem expandierten Schlüssel einen verschlüsselten Block generiert: Es beginnt mit einer Anfangsrunde (initial round), wobei nur AddRoundKey angewandt wird. Danach folgen die 10 Hauptrunden, welche die vier Grundfunktionen mit jeweils dem der Runde entsprechenden Teilschlüssel aufrufen (Ausnahme ist die Schlussrunde, bei der die Funktion MixColumn ausgelassen wird). Der fertige Block wird dann als Rückgabewert zurückgegeben. 2. Die Entschlüsselung Die Entschlüsselung ist ein weiterer Hauptbestandteil des Algorithmus. Sie unterscheidet sich nicht besonders von der Verschlüsselung, außer dass eine andere S-Box benutzt wird, sowie bei Mixcolumn andere Polynome. Der Großteil ist zu Verschlüsselung äquivalent und läuft eigentlich nur rückwärts: 2.1. AddRoundKey: AddRoundkey stellt einen Sonderfall da: Da XOR-Operationen selbstinvers sind, d.h nach doppelter Anwendung entsteht wieder der Ausgangswert, kann die Funktion genau so bleiben wie sie ist, wir brauchen keinen Pendant. 195

23 2.2. InvSubBytes: InvSubbytes benötigt eine andere Substitutionstabelle als SubBytes: Der Unterschied der Funktion InvSubBytes zur Funktion SubBytes ist minimal: nur die Substitutionstabelle ändert sich: 2.3. InvShiftRows: InvShiftRows ändert sich nur dahingehend, dass die Verschiebung in die andere Richtung hin erfolgt: 196

24 2.4. MixColumn: Die komplizierte MixColumn-Funktion ändert sich nur im Hauptteil, wobei andere Polynome verwendet werden: 197

25 Das Pendant zu der Funktion encryptblock, decryptblock läuft im Vergleich zu encryptblock genau rückwärts: (High(x) liefert den Index des höchsten Elements des dynamischen Arrays) 3. Die Schlüsselexpansion (Key Schedule) Hierbei werden aus dem Startschlüssel, welcher als einfach TBlock gesehen werden kann, die 10/12/14 weiteren Rundenschlüssel erzeugt, so dass schließlich 198

26 10+1/12+1/13+1 Schlüssel vorliegen. Diese können in einem Array gespeichert werden, welcher als Array von TBlock definiert werden kann: TCipherTable enthält die 10+1/12+1/14+1 Rundenschlüssel vom Typ TBlock, auf die wieder per ciphertable[x] zugegriffen werden kann. Kommen wir zu den einzelnen Funktionen: Diese lassen sich in zwei Teile aufteilen: den Kern (core), welcher nur für die erste Spalte des neuen Blocks zum Einsatz kommt die XOR-Verknüpfung der Spalten W-1 und W-4 zu der neuen Spalte (siehe oben) 3.1. RowWord: Die Funktion RotWord verschiebt die Zellen innerhalb einer Spalte einfach um eins nach unten: 3.2. SubWord/SubBytes: SubWord macht im Prinzip genau das wie SubBytes, nur auf Spaltenebene: 199

27 3.3. Rcon: Rcon liefert für einen bestimmten Wert (der der aktuellen Runde entspricht) eine Spalte des Aufbaus {x, 0, 0, 0}, wobei x der von Rcon erzeugte Wert ist. RconTable ist wieder ein vordefinierter Array (ähnlich SubBytes): Die Implementation von Rcon sieht dann so aus: Diese drei Einzelfunktionen, die den Kern bilden, können auch zu einer Funktion zusammengefasst werden, die anschließend etwas vereinfacht wird. Die Funktion core bekommt für rcon die Runden und die Spalte übergeben, welche wieder zurückgegeben wird (var-parameter übergibt das Original, nicht wie sonst eine Kopie des Speicherbereichs). Hier also die core-funktion: 200

28 Die Verknüpfung der Spalten per XOR können wir sodann in die Hauptfunktion einbauen: 201

29 202

30 Die obige Hauptfunktion (expandkey) erhält den Benutzerschlüssel (als array of byte), die Länge, auf welche expandiert werden soll (in Byte) und die Länge des Schlüssel (in Byte). Zuerst werden einige Werte initialisiert. Dann wird die Länge des Rückgabewerts, der als dynamischer Array definiert ist, festgelegt. Als nächstes wird der Benutzerschlüssel per for-schleife schon einmal in den expandierten Schlüssel kopiert und die aktuelle Position wird aktualisiert. Dann beginnt die eigentliche Schlüsselerweiterung: Zuerst wird die letzte Spalte des vorherigen Blocks in den temporären Zwischenspeicher t kopiert. Falls wir uns jetzt am Anfang eines neuen Blocks befinden, wird der core aufgerufen (RotWord, SubBytes, Rcon). Bei AES256 gibt es die Besonderheit, dass zusätzlich noch die mittlere Spalte per S-Box substituiert wird. Dann werden diese Spalte und die Spalte 4 davor (W-4) per XOR verknüpft. Das resultierende Ergebnis ist die nächste Spalte des aktuellen Blocks. Dieser ganze Vorgang wird solange wiederholt, bis die gewünschte Schlüssellänge erreicht ist. Nun sollten wir noch eine Funktion erstellen, die uns aus einem eingegeben Schlüssel als String und der Angabe des AES-Modus den erweiterten Schlüssel generiert. Aus dem Passwort wird ein 128bit/192bit/256bit Hash erzeugt. Hierbei ist der sogenannte Haval-Algorithmus vorteilhaft, da man bei ihm die gewünschte Länge des Hash s angeben kann. Andere Hash-Algorithmen wie MD5 haben dagegen eine einzige, konstante Länge. Hier nun die endgültige Hauptfunktion für die Schlüsselexpansion: 203

31 Zuerst werden anhand des AES-Typs die entsprechenden Parameter festgelegt. Dann werden die Längen des Benutzerschlüssels, des erweiterten Schlüssels als Bytearray und des erweiterten Schlüssels als Array of TBlock festgelegt. Dann wird von dem Passwort ein Hash (Benutzerschlüssel) erzeugt und von einem Hex-String in einen Array of Byte umgewandelt. Nun wird der Schlüssel expandiert und danach in einen Array off TBlock umgewandelt, welcher dann verwendet wird. 204

32 Damit wäre der AES-Algorithmus fertig gestellt, zumindest soweit wie er offiziell festgelegt ist (außer der Art des Umwandelns des Passwortes). Für den Rest, also wie die Daten bzw. die Datei in die für den Blockalgorithmus benötigten 16-Byte (128bit) Blöcke zerlegt wird, gibt es keine offiziellen Richtlinien, jedoch wird meistens nach folgendem Prinzip vorgegangen: Die Datei wird solange in 16 Byte-Blöcken eingelesen und verarbeitet, bis die Restgröße <= 16 ist. Da der Blockalgorithmus aber nur mit 16Byte Blöcken arbeiten kann, muss die Datei meistens erweitert, also mit Fülldaten aufgefüllt ( gepaddet ) werden. Damit jedoch dadurch die ursprüngliche Datei beim Entschlüsseln nicht zerstört wird, wird immer mit einem eindeutigen Muster aufgefüllt. Für den Fall, dass die Restgröße 16 ist, also die Dateigröße durch 16 ganz teilbar ist (Size mod 16 = 0), wird ein ganzer neuer Block erzeugt. Dieser beginnt mit einer Eins und enthält ansonsten nur Nullen. Für den wahrscheinlicheren Fall, dass die Restgröße < 16 ist, wird der Rest, begonnen mit einer 1, mit Nullen aufgefüllt, bis die Größe stimmt, was die Datei dann natürlich entsprechend größer werden lässt. Wenn die Restgröße = 15 ist, hat dies ungünstigerweise zur Folge, dass nun eine 1 aufgefüllt wird und der Block damit voll ist. Damit das Ende trotzdem identifiziert werden kann, wird ein ganzer weiterer Block mit Nullen erzeugt, so dass die Ausgabedatei dann 16 Byte größer ist als der Input. Dies ist die maximale Größenänderung, die jedoch nur für die Fälle Restgröße = 16 und Restgröße = 15 eintritt. Ein paar Beispiele: Das Ende der Datei ist genau 16 Byte groß: abeög5b3sl9äv73n (16Z) dann folgt daraus: abeög5b3sl9äv73n (32Z) Bei einem 15Byte großen Ende: abeög5b3sl9äv73 (15Z) Dann: abeög5b3sl9äv (32Z) Bei 14Byte: abeög5b3sl9äv7 (14Z) dann: abeög5b3sl9äv710 (16Z) 205

33 Und abschließend noch z.b. 5Byte: abeög (5Z) Dann: abeög (16Z) Nun gibt es bei Blockchiffren verschiedene Betriebsarten. Die zwei Standard-Modi sind: ECB (Electronic Code Book Mode) CBC (Cipher Block Chaining Mode) ECB ist der einfachste aber auch unsicherste Modus. Die Klartextblöcke werden nacheinander und unabhängig voneinander verschlüsselt. Dies ist nicht ganz risikolos, denn dadurch werden Klartextmuster nicht verwischt. Gleiche Klartextblöcke ergeben (bei gleichen Schlüssel) auch immer den gleichen Geheimtextblock. Dadurch kann man, hinreichend vielen Geheimtextblöcken und partiellen Annahmen über den Klartext, Rückschlüsse auf den geheimen Schlüssel ziehen. Dazu eine Grafik: CBC ist dagegen sicherer, aber auch aufwändiger, vor allem deswegen, weil ein Initialisierungsvektor benötigt wird, der meistens aus Zufallszahlen besteht und der neben dem geheimen Schlüssel mit übertragen werden muss. Allerdings kann der Initialisierungsvektor auch öffentlich sein, es ist keinen zusätzlichen Schutz, ihn geheim zu halten. Der Vorteil ist, dass selbst genau die gleichen Daten zu unterschiedlichen Outputs führen, wenn sich die Initialisierungsvektoren 206

34 unterscheiden. CBC funktioniert folgendermaßen: Vor dem Verschlüsseln eines Klartextblocks wird dieser zuvor mit dem im letzten Schritt erzeugten Geheimtextblock per XOR verknüpft. Dazu ist bei der ersten Verschlüsselung allerdings ein IV notwendig. Den Vorgang nochmals als Grafik: bzw. bei der Entschlüsselung: 207

35 Bemerkungen zum Beispielprogramm Das Beispielprogramm, das sich in den Begleitdateien befindet, ist aufgeteilt in Algorithmus und Frontend. So ist der Quellcode des Algorithmus auf einfache Weise wiederzuverwenden. Für eine bessere Performance ist der Algorithmus noch in einen Thread gekapselt. Das Frontend bietet alle Möglichkeiten von AES an: Die Wahl des Modi: AES128, AES192, AES256 Ver- oder Entschlüsseln Zusätzlich wird zwischen einem Datei- und Textmodus unterschieden, wobei der Textmodus allerdings intern auf dem Dateimodus aufsetzt. Aufgrund der Tatsache, dass bei der Verschlüsselung #0 (ASCII NULL-Zeichen) entstehen können, kann der verschlüsselte Text beim Textmodus nicht in einem zweiten Memo angezeigt werden. Dies liegt daran, dass die VCL von Delphi noch nicht Unicode fähig ist und daher noch normale Strings verwendet werden, welche #0 als Endzeichen interpretieren. Deshalb wird der Umweg über den Windows-Editor gegangen. Der Algorithmus benutzt das ECB-Verfahren, es sollte jedoch kein allzu großes Problem sei, ihn um eine Wahlmöglichkeit und andere Verfahren zu erweitern. Zu bemerken ist noch, dass der Algorithmus eher auf Verständlichkeit als auf Schnelligkeit getrimmt ist. So müsste man die Daten nicht als zweidimensionalen Array verwalteten, was für den Computer schwieriger, für uns aber leichter zu verstehen ist. Zurzeit hat er einen Datendurchsatz von etwa 1 MB/s (AES128) bis 0,7 MB/s (AES256) beim Verschlüsseln und etwa 0,66 MB/s (AES128) bis 0,4 MB/s (AES256) beim Entschlüsseln. Die Geschwindigkeit könnte jedoch vor allem durch sogenannte forward and reverse tables (Vorwärts- und Rückwärts-Tabellen) spürbar erhöht werden (auf etwa 8MB/s), auf welche jedoch hier im Script aus Übersichtlichkeitsgründen verzichtet wurde. In den Begleitdateien findet sich eine optimierte Variante, die diese Tabellen benutzt, und sowohl in Hin- als auch in Rückrichtung einen Datendurchsatz von etwa 4,5-6MB/s erreicht. Begleitdateien AES_Beispiel_Programm (leichter, da zweidimensionale Arrays benutzt werden) AES_Beispiel_Programm_Optimiert (viel schneller, z.t. verständlicher) 208

36 Anhang Test-Vektoren V.1 AES-128 (Encrypt) Plaintext: Key: Output: aabbccddeeff a0b0c0d0e0f 69c4e0d86a7b0430d8cdb78070b4c55a (Decrypt) Input: Key: Plaintext: 69c4e0d86a7b0430d8cdb78070b4c55a a0b0c0d0e0f aabbccddeeff V.2 AES-192 (Encrypt) Plaintext: Key: Output: aabbccddeeff a0b0c0d0e0f dda97ca4864cdfe06eaf70a0ec0d7191 (Decrypt) Input: Key: Plaintext: dda97ca4864cdfe06eaf70a0ec0d a0b0c0d0e0f aabbccddeeff 209

37 V.3 AES-256 (Encrypt) Plaintext: Key: Output: aabbccddeeff a0b0c0d0e0f a1b1c1d1e1f 8ea2b7ca516745bfeafc49904b (Decrypt) Input: Key: Plaintext: 8ea2b7ca516745bfeafc49904b a0b0c0d0e0f a1b1c1d1e1f aabbccddeeff 210

38 Vollständige Test-Vektoren-Übersicht: Legende: input: iinput: start: istart: s_box: is_box: s_row: is_row: k_sch: ik_sch: ik_add: output: Cipher input inverse cipher input State am Anfang von rounde[r] State am Anfang von rounde[r] State nach SubBytes() State nach InvSubBytes() State nach ShiftRows() State nach InvShiftRows() Rundenschlüssel für runde[r] Rundenschlüssel für round[r] State nach AddRoundKey Cipher output C.1 AES-128 PLAINTEXT: aabbccddeeff KEY: a0b0c0d0e0f CIPHER (ENCRYPT): round[ 0].input aabbccddeeff round[ 0].k_sch a0b0c0d0e0f round[ 1].start a0b0c0d0e0f0 round[ 1].s_box 63cab d051cd60e0e7ba70e18c round[ 1].s_row 6353e08c0960e104cd70b751bacad0e7 round[ 1].m_col 5f f5bc92f7be3b291db9f91a round[ 1].k_sch d6aa74fdd2af72fadaa678f1d6ab76fe round[ 2].start 89d810e8855ace682d1843d8cb128fe4 round[ 2].s_box a761ca9b97be8b45d8ad1a611fc97369 round[ 2].s_row a7be1a6997ad739bd8c9ca451f618b61 round[ 2].m_col ff d86a fa773ad009 round[ 2].k_sch b692cf0b643dbdf1be9bc b3fe round[ 3].start f55e5d7a0daca94fa1f0a63f7 round[ 3].s_box 3b59cb73fcd90ee dc067fb68 round[ 3].s_row 3bd92268fc74fb735767cbe0c0590e2d round[ 3].m_col 4c9c1e66f771f0762c3f868e534df256 round[ 3].k_sch b6ff744ed2c2c9bf6c590cbf0469bf41 round[ 4].start fa636a2825b339c940668a d17 round[ 4].s_box 2dfb02343f6d12dd09337ec75b36e3f0 round[ 4].s_row 2d6d7ef03f33e dd5bfb12c7 round[ 4].m_col 6385b79ffc538df997be478e7547d691 round[ 4].k_sch 47f7f7bc95353e03f96c32bcfd058dfd round[ 5].start b3fa6ed b6c round[ 5].s_box f9336d2d9fb59d23c42c3950 round[ 5].s_row 36339d50f9b539269f2c092dc4406d23 round[ 5].m_col f4bcd45432e554d075f1d6c51dd03b3c 211

39 round[ 5].k_sch round[ 6].start round[ 6].s_box round[ 6].s_row round[ 6].m_col round[ 6].k_sch round[ 7].start round[ 7].s_box round[ 7].s_row round[ 7].m_col round[ 7].k_sch round[ 8].start round[ 8].s_box round[ 8].s_row round[ 8].m_col round[ 8].k_sch round[ 9].start round[ 9].s_box round[ 9].s_row round[ 9].m_col round[ 9].k_sch round[10].start round[10].s_box round[10].s_row round[10].k_sch round[10].output 3caaa3e8a99f9deb50f3af57adf622aa c81677bc9b7ac93b b e847f56514dadde23f77b64fe7f7d490 e8dab d4653ff7f5e2e747dd4f 9816ee7400f87f556b2c049c8e5ad036 5e390f7df7a69296a7553dc10aa31f6b c62fe109f75eedc3cc79395d84f9cf5d b415f e4bb6124c5f998a4c b458124c68b68a014b99f82e5f15554c c57e1c159a9bd286f05f4be098c f9701ae35fe28c440adf4d4ea9c026 d1876c0f79c4300ab45594add66ff41f 3e175076b61c04678dfc2295f6a8bfc0 3e1c22c0b6fcbf768da85067f baa03de7a1f9b56ed5512cba5f414d a41c65b9e016baf4aebf7ad2 fde3bad205e5d0d ef1fe37f1 5411f4b56bd9700e96a0902fa1bb9aa1 54d990a16ba09ab596bbf40ea111702f e9f74eec023020f61bf2ccf2353c21c d1f ed9cbe2c974e bd6e7c3df2b5779e0b61216e8b10b689 7a9f102789d5f50b2beffd9f3dca4ea7 7ad5fda789ef4e272bca100b3d9ff59f 13111d7fe3944a17f307a78b4d2b30c5 69c4e0d86a7b0430d8cdb78070b4c55a INVERSE CIPHER (DECRYPT): round[ 0].iinput 69c4e0d86a7b0430d8cdb78070b4c55a round[ 0].ik_sch 13111d7fe3944a17f307a78b4d2b30c5 round[ 1].istart 7ad5fda789ef4e272bca100b3d9ff59f round[ 1].is_row 7a9f102789d5f50b2beffd9f3dca4ea7 round[ 1].is_box bd6e7c3df2b5779e0b61216e8b10b689 round[ 1].ik_sch d1f ed9cbe2c974e round[ 1].ik_add e9f74eec023020f61bf2ccf2353c21c7 round[ 2].istart 54d990a16ba09ab596bbf40ea111702f round[ 2].is_row 5411f4b56bd9700e96a0902fa1bb9aa1 round[ 2].is_box fde3bad205e5d0d ef1fe37f1 round[ 2].ik_sch a41c65b9e016baf4aebf7ad2 round[ 2].ik_add baa03de7a1f9b56ed5512cba5f414d23 round[ 3].istart 3e1c22c0b6fcbf768da85067f round[ 3].is_row 3e175076b61c04678dfc2295f6a8bfc0 round[ 3].is_box d1876c0f79c4300ab45594add66ff41f round[ 3].ik_sch 14f9701ae35fe28c440adf4d4ea9c026 round[ 3].ik_add c57e1c159a9bd286f05f4be098c63439 round[ 4].istart b458124c68b68a014b99f82e5f15554c round[ 4].is_row b415f e4bb6124c5f998a4c round[ 4].is_box c62fe109f75eedc3cc79395d84f9cf5d round[ 4].ik_sch 5e390f7df7a69296a7553dc10aa31f6b round[ 4].ik_add 9816ee7400f87f556b2c049c8e5ad036 round[ 5].istart e8dab d4653ff7f5e2e747dd4f 212

40 round[ 5].is_row round[ 5].is_box round[ 5].ik_sch round[ 5].ik_add round[ 6].istart round[ 6].is_row round[ 6].is_box round[ 6].ik_sch round[ 6].ik_add round[ 7].istart round[ 7].is_row round[ 7].is_box round[ 7].ik_sch round[ 7].ik_add round[ 8].istart round[ 8].is_row round[ 8].is_box round[ 8].ik_sch round[ 8].ik_add round[ 9].istart round[ 9].is_row round[ 9].is_box round[ 9].ik_sch round[ 9].ik_add round[10].istart round[10].is_row round[10].is_box round[10].ik_sch round[10].ioutput e847f56514dadde23f77b64fe7f7d490 c81677bc9b7ac93b b caaa3e8a99f9deb50f3af57adf622aa f4bcd45432e554d075f1d6c51dd03b3c 36339d50f9b539269f2c092dc4406d f9336d2d9fb59d23c42c b3fa6ed b6c 47f7f7bc95353e03f96c32bcfd058dfd 6385b79ffc538df997be478e7547d691 2d6d7ef03f33e dd5bfb12c7 2dfb02343f6d12dd09337ec75b36e3f0 fa636a2825b339c940668a d17 b6ff744ed2c2c9bf6c590cbf0469bf41 4c9c1e66f771f0762c3f868e534df256 3bd92268fc74fb735767cbe0c0590e2d 3b59cb73fcd90ee dc067fb f55e5d7a0daca94fa1f0a63f7 b692cf0b643dbdf1be9bc b3fe ff d86a fa773ad009 a7be1a6997ad739bd8c9ca451f618b61 a761ca9b97be8b45d8ad1a611fc d810e8855ace682d1843d8cb128fe4 d6aa74fdd2af72fadaa678f1d6ab76fe 5f f5bc92f7be3b291db9f91a 6353e08c0960e104cd70b751bacad0e7 63cab d051cd60e0e7ba70e18c a0b0c0d0e0f a0b0c0d0e0f aabbccddeeff C.2 AES-192 PLAINTEXT: aabbccddeeff KEY: a0b0c0d0e0f CIPHER (ENCRYPT): round[ 0].input aabbccddeeff round[ 0].k_sch a0b0c0d0e0f round[ 1].start a0b0c0d0e0f0 round[ 1].s_box 63cab d051cd60e0e7ba70e18c round[ 1].s_row 6353e08c0960e104cd70b751bacad0e7 round[ 1].m_col 5f f5bc92f7be3b291db9f91a round[ 1].k_sch f2f95c43f4fe round[ 2].start 4f e0aa85aff8c9d041fa0de4 round[ 2].s_box 84fb386f1ae1ac977941dd70832dd769 round[ 2].s_row 84e1dd691a41d76f792d389783fbac70 round[ 2].m_col 9f487f794f955f662afc86abd7f1ab29 round[ 2].k_sch 544afef55847f0fa4856e2e95c43f4fe round[ 3].start cb02818c17d2af9c62aa64428bb25fd7 round[ 3].s_box 1f770c64f0b579deaaac432c3d37cf0e round[ 3].s_row 1fb5430ef0accf64aa370cde3d77792c 213

41 round[ 3].m_col round[ 3].k_sch round[ 4].start round[ 4].s_box round[ 4].s_row round[ 4].m_col round[ 4].k_sch round[ 5].start round[ 5].s_box round[ 5].s_row round[ 5].m_col round[ 5].k_sch round[ 6].start round[ 6].s_box round[ 6].s_row round[ 6].m_col round[ 6].k_sch round[ 7].start round[ 7].s_box round[ 7].s_row round[ 7].m_col round[ 7].k_sch round[ 8].start round[ 8].s_box round[ 8].s_row round[ 8].m_col round[ 8].k_sch round[ 9].start round[ 9].s_box round[ 9].s_row round[ 9].m_col round[ 9].k_sch round[10].start round[10].s_box round[10].s_row round[10].m_col round[10].k_sch round[11].start round[11].s_box round[11].s_row round[11].m_col round[11].k_sch round[12].start round[12].s_box round[12].s_row round[12].k_sch round[12].output b7a53ecbbf9d75a0c40efc79b674cc11 40f949b31cbabd4d48f043b810b7b342 f75c7778a327c8ed8cfebfc1a6c37f53 684af5bc0acce85564bb ed2ed 68cc08ed0abbd2bc642ef555244ae878 7a1e98bdacb6d1141a6944dd06eb2d3e 58e151ab04a2a5557effb c 22ffc916a f19c64ae dd47c2fa a1de43e43f23 93faa123c2903f4743e4dd de aaa755b34cffe57cef6f98e1f01c13e6 2ab54bb43a02f8f662e3a95d66410c e0776fd1d8a8d8c31bc965d1fee cdc972c53854a47e5d64c765904cc028 cd54c c0c55d4c727e90c9a f748fd96e937d622d7725ba8ba50c f d7ebdf1c6ca87f33e3c 671ef1fd4e2a1e03dfdcb1ef3d789b a1542fe5727b9e86c8df27bc e5c8042f ebca17b277272df e913e7b18f507d4b227ef652758acbcc e b c9ea351f1e0 0c0370d00c01e622166b8accd6db3a2c fe7b5170fe7c8e93477f7e4bf6b98071 fe7c7e71fe7f807047b95193f67b8e4b 6cf5edf996eb0a069c4ef21cbfc ea0372a c439e77ff12051e 7255dad30fb80310e00d6c6b40d0527c 40fc c7bcae1d7507f c501076d70066e17057ca09fc7b7f 7478bcdce8a50b81d4327a dd7e0e887e2fff68608fc842f9dcc154 a906b254968af4e9b4bdb2d2f0c44336 d36f ebf1e8d7a37b58c1c1a05 d37e a1a208d1c371e8c6fbfb5 0d73cc2d8f6abe8b0cf2dd9bb83d422e 859f5f237a8d5a3dc0c02952beefd63a 88ec930ef5e7e4b6cc32f4c906d29414 c4cedcabe694694e4b23bfdd6fb522fa c494bffae62322ab4bb5dc4e6fce69dd 71d720933b6d677dc00b8f28238e0fb7 de601e7827bcdf2ca223800fd8aeda32 afb73eeb1cd1b f27fb20d585 79a9b2e99c3e6cd1aa3476cc0fb e76979c3403e9aab7b2d10fa96ccc a4970a331a78dc09c418c271e3a41d5d dda97ca4864cdfe06eaf70a0ec0d7191 INVERSE CIPHER (DECRYPT): round[ 0].iinput dda97ca4864cdfe06eaf70a0ec0d7191 round[ 0].ik_sch a4970a331a78dc09c418c271e3a41d5d 214

42 round[ 1].istart round[ 1].is_row round[ 1].is_box round[ 1].ik_sch round[ 1].ik_add round[ 2].istart round[ 2].is_row round[ 2].is_box round[ 2].ik_sch round[ 2].ik_add round[ 3].istart round[ 3].is_row round[ 3].is_box round[ 3].ik_sch round[ 3].ik_add round[ 4].istart round[ 4].is_row round[ 4].is_box round[ 4].ik_sch round[ 4].ik_add round[ 5].istart round[ 5].is_row round[ 5].is_box round[ 5].ik_sch round[ 5].ik_add round[ 6].istart round[ 6].is_row round[ 6].is_box round[ 6].ik_sch round[ 6].ik_add round[ 7].istart round[ 7].is_row round[ 7].is_box round[ 7].ik_sch round[ 7].ik_add round[ 8].istart round[ 8].is_row round[ 8].is_box round[ 8].ik_sch round[ 8].ik_add round[ 9].istart round[ 9].is_row round[ 9].is_box round[ 9].ik_sch round[ 9].ik_add round[10].istart round[10].is_row round[10].is_box round[10].ik_sch round[10].ik_add round[11].istart 793e76979c3403e9aab7b2d10fa96ccc 79a9b2e99c3e6cd1aa3476cc0fb70397 afb73eeb1cd1b f27fb20d585 de601e7827bcdf2ca223800fd8aeda32 71d720933b6d677dc00b8f28238e0fb7 c494bffae62322ab4bb5dc4e6fce69dd c4cedcabe694694e4b23bfdd6fb522fa 88ec930ef5e7e4b6cc32f4c906d f5f237a8d5a3dc0c02952beefd63a 0d73cc2d8f6abe8b0cf2dd9bb83d422e d37e a1a208d1c371e8c6fbfb5 d36f ebf1e8d7a37b58c1c1a05 a906b254968af4e9b4bdb2d2f0c44336 dd7e0e887e2fff68608fc842f9dcc bcdce8a50b81d4327a c501076d70066e17057ca09fc7b7f 40fc c7bcae1d7507f dad30fb80310e00d6c6b40d0527c 1ea0372a c439e77ff12051e 6cf5edf996eb0a069c4ef21cbfc25762 fe7c7e71fe7f807047b95193f67b8e4b fe7b5170fe7c8e93477f7e4bf6b c0370d00c01e622166b8accd6db3a2c e b c9ea351f1e0 e913e7b18f507d4b227ef652758acbcc 85e5c8042f ebca17b277272df 8572a1542fe5727b9e86c8df27bc ef1fd4e2a1e03dfdcb1ef3d789b30 f d7ebdf1c6ca87f33e3c 921f748fd96e937d622d7725ba8ba50c cd54c c0c55d4c727e90c9a465 cdc972c53854a47e5d64c765904cc e0776fd1d8a8d8c31bc965d1fee 2ab54bb43a02f8f662e3a95d66410c08 aaa755b34cffe57cef6f98e1f01c13e6 93faa123c2903f4743e4dd de 9316dd47c2fa a1de43e43f23 22ffc916a f19c64ae e151ab04a2a5557effb c 7a1e98bdacb6d1141a6944dd06eb2d3e 68cc08ed0abbd2bc642ef555244ae af5bc0acce85564bb ed2ed f75c7778a327c8ed8cfebfc1a6c37f53 40f949b31cbabd4d48f043b810b7b342 b7a53ecbbf9d75a0c40efc79b674cc11 1fb5430ef0accf64aa370cde3d77792c 1f770c64f0b579deaaac432c3d37cf0e cb02818c17d2af9c62aa64428bb25fd7 544afef55847f0fa4856e2e95c43f4fe 9f487f794f955f662afc86abd7f1ab29 84e1dd691a41d76f792d389783fbac70 215

43 round[11].is_row round[11].is_box round[11].ik_sch round[11].ik_add round[12].istart round[12].is_row round[12].is_box round[12].ik_sch round[12].ioutput 84fb386f1ae1ac977941dd70832dd769 4f e0aa85aff8c9d041fa0de f2f95c43f4fe 5f f5bc92f7be3b291db9f91a 6353e08c0960e104cd70b751bacad0e7 63cab d051cd60e0e7ba70e18c a0b0c0d0e0f a0b0c0d0e0f aabbccddeeff C.3 AES-256 PLAINTEXT: aabbccddeeff KEY: a0b0c0d0e0f a1b1c1d1e1f CIPHER (ENCRYPT): round[ 0].input aabbccddeeff round[ 0].k_sch a0b0c0d0e0f round[ 1].start a0b0c0d0e0f0 round[ 1].s_box 63cab d051cd60e0e7ba70e18c round[ 1].s_row 6353e08c0960e104cd70b751bacad0e7 round[ 1].m_col 5f f5bc92f7be3b291db9f91a round[ 1].k_sch a1b1c1d1e1f round[ 2].start 4f e0aa85efa a4e705 round[ 2].s_box 84fb386f1ae1ac97df5cfd237c49946b round[ 2].s_row 84e1fd6b1a5c946fdf cfbac23 round[ 2].m_col bd2a395d2b6ac438d192443e615da195 round[ 2].k_sch a573c29fa176c498a97fce93a572c09c round[ 3].start 1859fbc28a1c00a078ed8aadc42f6109 round[ 3].s_box adcb0f257e9c63e0bc557e951c15ef01 round[ 3].s_row ad9c7e017e55ef25bc150fe01ccb6395 round[ 3].m_col 810dce0cc9db8172b3678c1e88a1b5bd round[ 3].k_sch 1651a8cd0244beda1a5da4c10640bade round[ 4].start 975c66c1cb9f3fa8a93a28df8ee10f63 round[ 4].s_box 884a33781fdb75c2d380349e19f876fb round[ 4].s_row 88db34fb1f807678d3f833c2194a759e round[ 4].m_col b2822d81abe6fb275faf103a078c0033 round[ 4].k_sch ae87dff00ff11b68a68ed5fb03fc1567 round[ 5].start 1c05f271a417e04ff921c5c round[ 5].s_box 9c6b89a349f0e18499fda678f round[ 5].s_row 9cf0a62049fd59a f26be178 round[ 5].m_col aeb65ba974e0f822d73f567bdb64c877 round[ 5].k_sch 6de1f1486fa54f9275f8eb5373b8518d round[ 6].start c357aae11b45b7b0a2c7bd28a8dc99fa round[ 6].s_box 2e5bacf8af6ea9e73ac67a34c286ee2d round[ 6].s_row 2e6e7a2dafc6eef83a86ace7c25ba934 round[ 6].m_col b951c33c02e9bd29ae25cdb1efa08cc7 round[ 6].k_sch c656827fc9a799176f294cec6cd5598b round[ 7].start 7f074143cb4e243ec10c815d8375d54c round[ 7].s_box d2c5831a1f2f36b278fe0c4cec9d0329 round[ 7].s_row d22f0c291ffe031a789d83b2ecc5364c round[ 7].m_col ebb19e1c3ee7c9e87d7535e9ed6b

44 round[ 7].k_sch round[ 8].start round[ 8].s_box round[ 8].s_row round[ 8].m_col round[ 8].k_sch round[ 9].start round[ 9].s_box round[ 9].s_row round[ 9].m_col round[ 9].k_sch round[10].start round[10].s_box round[10].s_row round[10].m_col round[10].k_sch round[11].start round[11].s_box round[11].s_row round[11].m_col round[11].k_sch round[12].start round[12].s_box round[12].s_row round[12].m_col round[12].k_sch round[13].start round[13].s_box round[13].s_row round[13].m_col round[13].k_sch round[14].start round[14].s_box round[14].s_row round[14].k_sch round[14].output 3de23a e727bf9eb45407cf39 d653a4696ca0bc0f5acaab5db96c5e7d f6ed49f950e06576be74624c565058ff f6e062ff507458f9be ed654c 5174c8669da98435a8b3e62ca974a5ea 0bdc905fc27b0948ad5245a4c1871c2f 5aa858395fd28d7d05e1a38868f3b9c5 bec26a12cfb55dff6bf80ac4450d56a6 beb50aa6cff856126b0d6aff45c25dc4 0f77ee31d2ccadc05430a83f4ef96ac3 45f5a66017b2d387300d4d33640a820a 4a824851c57e7e47643de50c2af3e8c9 d61352d1a6f3f3a04327d9fee50d9bdd d6f3d9dda6279bd1430d52a0e513f3fe bd86f0ea748fc4f4630f11c1e ccff71cbeb4fe5413e6bbf0d261a7df c14907f6ca3b3aa070e9aa313b52b5ec 783bc54274e280e0511eacc7e200d5ce 78e2acce741ed c5e0e23b80c7 af d6e1dd387e5fbedd5c89013 f01afafee7a82979d7a5644ab3afe640 5f9c6abfbac634aa50409fa cfde0208f4b418ac5309db5c338538ed cfb4dbedf ac33de185c 7427fae4d8a695269ce83d315be0392b 2541fe719bf bbd55a721c0a fb86e d133f22a1aed2a7bfa0f44697c4f3ffd d1ed44fd1a0f3f2afa4ff27b7c332a69 2c21a820306f154ab712c75eee0da04f 4e5a6699a9f24fe07e572baacdf8cdea 627bceb9999d5aaac945ecf423f56da5 aa218b56ee5ebeacdd6ecebf26e63c06 aa5ece06ee6e3c56dde68bac2621bebf 24fc79ccbf0979e9371ac23c6d68de36 8ea2b7ca516745bfeafc49904b INVERSE CIPHER (DECRYPT): round[ 0].iinput 8ea2b7ca516745bfeafc49904b round[ 0].ik_sch 24fc79ccbf0979e9371ac23c6d68de36 round[ 1].istart aa5ece06ee6e3c56dde68bac2621bebf round[ 1].is_row aa218b56ee5ebeacdd6ecebf26e63c06 round[ 1].is_box 627bceb9999d5aaac945ecf423f56da5 round[ 1].ik_sch 4e5a6699a9f24fe07e572baacdf8cdea round[ 1].ik_add 2c21a820306f154ab712c75eee0da04f round[ 2].istart d1ed44fd1a0f3f2afa4ff27b7c332a69 round[ 2].is_row d133f22a1aed2a7bfa0f44697c4f3ffd round[ 2].is_box fb86e round[ 2].ik_sch 2541fe719bf bbd55a721c0a round[ 2].ik_add 7427fae4d8a695269ce83d315be0392b round[ 3].istart cfb4dbedf ac33de185c 217