0 like 0 dislike

Wie funktioniert das Oracle Padding im Detail? Bzw. warum funktioniert es? Ich verstehe, dass wir verschiedene Anfragen an einen Server sendet, und dieser uns beantwortet, ob das Padding in Ordnung ist. Aber warum müssen wir nun Stück für Stück das Padding bis zum Ende erhöhen? Der Wert (im ersten Schritt z.B. 0x01) repräsentiert ja nicht unseren echten Wert, der im mx stehen müsste. Daher verstehe ich nicht wie man dadurch auf einen echten Wert kommt am Ende. Im gleichen Zug frage ich mich, ob man das nun für alle Blöcke M1...Mn anwenden kann und ob man gleichzeitig für jeden Block das Padding neu hochzählen muss.

in Vorlesung by
edit history

1 Answer

0 like 0 dislike
Best answer
Ich verwende einfach mal E(k, m) für die Block-Cipher-Encryption-Funktion des Plaintext m mit Schlüssel k, D(k, c) für die Block-Cipher-Decryption-Funktion des Ciphertext c mit Schlüssel k und ^ als XOR Symbol. Wenn du jetzt eine Nachricht m verschlüsselst, dann wählst du Initialisierungsvektor IV (uniform zufällig) und berechnest c = E(k, (m ^ IV)). Beim Entschlüsseln eines Ciphertexts c mit IV berechnest du IV ^ D(k, c) = IV ^ D(k, E(k, (m ^ IV))) = IV ^ m ^ IV = m.

Dabei hast du jetzt leider nicht den Schlüssel k als Angreifer, was du aber machen könntest, wäre verschiedene IV' auszuprobieren, bist du einen validen IV' gefunden hast (in Bezug auf das Padding).

(Sei y[i] das i-te Byte eines Blocks y, also z.B. y = FF FF FF 02 hat y[4] = 02. Wir haben jetzt aber in der Vorlesung 16-Byte Blöcke verwendet, also mache ich das einfach mal auch.)

Denn mit dem validen IV' weißt du (zuerst vereinfachende Annahme, dass einfach nur 0x01 das valide Padding ist, wie auch in der Vorlesung. Das ist auch mit sehr hoher Wahrscheinlichkeit tatsächlich der Fall, wenn du ein valides Padding gefunden hast), dass (IV' ^ D(k, c))[16] = IV'[16] ^ D(k, c)[16] = 0x01, denn andernfalls wäre das Padding nicht valide gewesen (andernfalls hätte der Server also einen Fehler geworfen). Aber dann folgt

IV'[16] ^ D(k, c)[16] ^ D(k, c)[16] = 0x01 ^ D(k, c)[16]
IV'[16] = 0x01 ^ D(k, c)[16]
0x01 ^ IV'[16] = 0x01 ^ 0x01 ^ D(k, c)[16]
0x01 ^ IV'[16] = D(k, c)[16]

D.h. du kannst also D(k, c)[16] berechnen, also das 16te Byte von D(k, c)!

Aber du hast auch bereits IV gegeben (ist in der Verschlüsselten Nachricht mit dabei), d.h. du kannst IV[16] ^ D(k, c)[16] = m[16] berechnen, also das 16te Byte von m!

Ferner kennst du auch schon einen IV', der die beim XORen beim 16ten Byte eine 0x01 liefert, d.h. wenn du den leicht modifizierst, hast du ein IV'' der beim XORen beim 16ten Byte eine 0x02 liefert. Dabei wird ja zum XORen nur das 16te Byte gebraucht, d.h. wenn du das jetzt gleich lässt aber andere Bytes änderst bleibt das letzte Byte immer noch 0x02. Jetzt kannst du das 15te (vorletzte) Byte des IV'' solange anpassen, bis du wieder ein valides Padding kriegst (also der Server ein OK gibt). Denn wir wissen nach den Padding-Regeln, dass das nur genau dann eintrifft, wenn das 15te Byte nach dem XORen eine 0x02 ist (man braucht für das 15te und 16te Byte ein 0x02). Genau wie oben kannst du nun also durch diese Information das 15te Byte von D(k, c) und damit auch m bestimmen. Wenn du das weiter durchexerzierst erhälst du schließlich alle Bytes von m.

Das galt jetzt aber nur für einen Block m. Dieses Verfahren musst du für alle Blöcke wiederholen, wobei aber der Initialisierungsvektor IV von Block c_i dann c_{i-1} ist (nur bei c_1 ist es IV).
by
edit history