encryptECB

[SEHellFire]

Der (Beispiel-)Quelltext für encryptECB weicht erheblich von der Funktionsbeschreibung im PDF ab.

Im Quelltext wird XOR verwendet in der Beschreibung nicht.

[asitplus-pteufl]

bitte den code berücksichtigen, stellen im dokument werden überprüft.

[asitplus-pteufl]

es wurden die letzten zwei Absätze von ECB und CFB vertauscht.
Dies ist der korrekte Text (wird in der nächsten Version berücksichtigt, bzw. jetzt als Known Issue definiert):

---

In diesem Fall wird davon ausgegangen, dass die in der jeweiligen Architektur verwendete Bibliothek für das Anwenden des AES-Algorithmus den ICM/CTR Modus NICHT unterstützt. Das ICM/CTR Verfahren kann aber über den CFB- oder ECB-Modus emuliert werden.
Die Daten (IV, Klartextdaten, AES-Schlüssel) werden gleich wie im ICM/CTR Modus aufbereitet.

Vorgehen für ECB-Modus:
• Initialisierung des AES-Algorithmus: Der AES Algorithmus wird mit dem ECB Modus ohne Padding-Schema und dem gegebenen AES-Schlüssel initialisiert. In diesem Modus verwendet der AES-Algorithmus keinen Initialisierungsvektor.
• Verschlüsselung des im vorigen Prozess definierten IVs: Der im Prozess 2.5.2 erstellte Initialisierungsvektor wird mit dem initialisierten AES-Algorithmus verschlüsselt. Das Ergebnis ist ein 16-Bytes/128 Bits langer Wert. Dieser Wert stellt den Schlüssel für die weitere Verschlüsselung des Umsatzzählers dar.
• Verschlüsseln des Umsatzzählers: Die im vorigen Prozess aufbereiteten Klartextdaten (der kodierte Umsatzzähler) werden mit dem im vorigen Schritt berechneten Schüssel über die XOR-Operation verknüpft. Das Ergebnis entspricht dem verschlüsselten Umsatzzähler – ein 16-Bytes/128 Bits langer Wert.

Vorgehen für CFB-Modus:
• Initialisierung des AES-Algorithmus: Der AES Algorithmus wird mit dem CFB Modus ohne Padding-Schema und dem gegeben AES-Schlüssel initialisiert. Als Initialisierungsvektor wird der im Prozess 2.5.2 erstellte IV verwendet.
Verschlüsseln des Umsatzzählers: Die im vorigen Schritt aufbereiteten Klartextdaten werden mit dem initialisierten AES-Algorithmus im CFB-Modus mit Hilfe der jeweiligen Bibliothek verschlüsselt. Das Ergebnis ist ein 16-Bytes/128 Bits langer Wert.

[ct-graz]

Vielleicht kann man einfach schreiben, dass es egal ist, ob man die Verschlüsselung mit ICM/CTR oder CFB aufruft/initialisiert.

[asitplus-pteufl]

ja, der absatz muss sowieso überarbeitet werden, da wäre diese anmerkung sehr sinnvoll.

[SEHellFire]

Es sind nur die ersten 8 Bytes identisch. (Siehe Anmerkungen im Quelltext)
Verschlüsselt man die vollen 16 Bytes mit CFB, dann wird das Ergebnis falsch.

[asitplus-pteufl]

nein, CFB und ICM sind exakt gleich (beim ersten Block, weil dann die IVs abweichen werden).

[SEHellFire]

Wenn ich das richtig verstanden habe würde bei ICM bereits nach 8 Bytes die erste Verschiebung auftreten.

Daher muss man wohl auch nur 8 Bytes hernehmen und mit 8 Null-Bytes zu 16 Bytes auffüllen.
Dann mit CFB ohne padding verschlüsseln.
Dann vom Ergebnis nur die ersten 8 Bytes hernehmen und als verschlüsselten Wert übernehmen.

Vermutung:
Würde man hier die vollen 16 Bytes als Ergebnis nehmen oder mehr als 8 Bytes von vornherein mit CFB verschlüsseln, dann wird das Ergebnis wohl nicht mit ICM entschlüsselbar sein.
Leider kann ich meine Vermutung nicht überprüfen, da mit .NET kein ICM funktioniert. Kann das jemand testen und bestätigen oder berichtigen?

[asitplus-pteufl]

Trennen wir das auf zwei Perspektiven auf:
-Die Verwendung ICM/CFB bzw. das Ergebnis ist für den ersten Block (16 bytes) exakt gleich (bei gleichem IV/Schlüssel).

-In unserem Fall nehmen wir nur 8 Bytes (oder auch nur 5) ohne Padding. Das "Padding" ist hinfällig da man aufgrund der Größeneinschränkungen vom 16 byte Ergebnis nur die notwendigen Bytes nimmt (das funktioniert nur im ICM/CFB Modus da nur hier durch XOR ein 1-zu-1 Mapping zwischen Plain/Verschlüsselten Text besteht). D.h. natürlich auch dass beim Entschlüsselungsvorgang wo man nur mehr die ersten 5 (oder 8) Bytes zur Verfügung hat, nach dem Entschlüsselungs-Ergebnis für die restlichen Bytes ein "Blödsinn" rauskommt, da man nicht mehr den gesamten verschlüsselten Block hat (und AES halt immer auf einen gesamten 16 Byte Block geht). Das ist aber egal, da man die nicht benötigten Bytes sowieso wieder einfach verwerfen kann. (Was man vorher beim Entschlüsseln einträgt für die nicht vorhandenen bytes ist egal, wird nachher eh wieder verworfen).