CTR Mode

[hstr]

Hallo,
da man im CTR Modus ja kein padding benötigt, muss man ja irgendwie bits aus der Funktion abschneiden. Aber wie?
Z.B.:
m = 10000001 ( Länge 8 ) und IV = 10000 ( Länge 5 ).
Nach Übung 9 kann man wie folgt Verschlüsseln: c_i = m_i XOR f(k, ctr+i (mod 2^n))
Man verschlüsselt also die ersten 5 bits (da f auf 5 bits abbildet): c_0 = 10000 XOR 10001 = 00001
Jetzt möchte man die nächsten 3 bits verschlüsseln: c_1 = 001 XOR 11100 = ?
Was muss man jetzt machen?
c_1 = 001 XOR 111 oder c_1 = 001 XOR 100?

[jens1234]

ich habe das leider auch nicht verstanden, bin eben auf das gleiche problem gestoßen.finde man kann das nicht aus dem skript herauslesen...

[jens1234]

weiß jemand ob es in der kommenden Woche Sprechstunden gibt?

[mmi1991]

Auch wenn CTR kein Padding benötigt, habe ich erstmal einfach die initiale Nachricht bei Schritt 1 gepadded, um das Problem zu umgehen. Ob das gewollt ist, weiß ich allerdings nicht…

[R_Egert]

Hallo zusammen,

Die Tatsache dass man bei diesem Modus (sowie OFB und CFB) kein wirkliches Padding benötigt liegt darin begründet, dass die Klartextblöcke mit der Ausgabe der eigentlichen Blockchiffre geXORed werden wodurch automatisch ein Block der von der Länge des letzten Klartextblocks erzeugt wird. Falls die Ausgabe der Blockchiffre länger ist als der zu verschlüsselnde Klartexblock, so werden die niederwertigsten Bits der Ausgabe für das XOR verwendet.

Somit ist kein initiales Padding notwendig

Viele Grüße,

Rolf

[hstr]

D.h. c_1 = 001 XOR 100 im obigen Beispiel?

[mmi1991]

Die Tatsache dass man bei diesem Modus (sowie OFB und CFB) kein wirkliches Padding benötigt …
Somit ist kein initiales Padding notwendig

Ich dachte, dass nach der CFB-Entschlüsselung entpadded wird (auch wenn es eigentlich nicht unbedingt notwendig wäre). Sonst frage ich mich, warum der Hinweis 5 (Für den sehr unwahrscheinlichen Fall, dass Sie für \(m^{(2)}\) den leeren String erhalten würden, setzten Sie \(m^{(2)}\) = …) im zweiten Schritt genannt wird. Wie soll sonst der leere String entstehen können?

[R_Egert]

Ich meinte damit dass es im allgemeinen nicht notwendig ist, da das XOR ja schon für die richtigen Längen sorgt, das soll nicht heißen, dass man es nicht verwendet, da so z.b. Längenunterschiede im letzten Block auftreten. Wenn es in der VL mit Padding verwendet wurde ist das natürlich so zu handeln

D.h. c_1 = 001 XOR 100 im obigen Beispiel?

Sollte so passen.

Viele Grüße,

Rolf

[hstr]

D.h. c_1 = 001 XOR 100 im obigen Beispiel?

Sollte so passen.
Rolf

Ok, Danke.

Ich dachte, dass nach der CFB-Entschlüsselung entpadded wird (auch wenn es eigentlich nicht unbedingt notwendig wäre). Sonst frage ich mich, warum der Hinweis 5 (Für den sehr unwahrscheinlichen Fall, dass Sie für \(m^{(2)}\) den leeren String erhalten würden, setzten Sie \(m^{(2)}\) = …) im zweiten Schritt genannt wird. Wie soll sonst der leere String entstehen können?

Ich vermute das wir dem Chiffrat aus dem ersten Schritt (CTR, nach meinem Beispiel: c_0 c_1 = 00001 101) ein Padding hinzufügen und dann 00001 10110 mit CFB entschlüsseln sollen.
(Wobei aber laut Wikipedia eigentlich kein Padding verwendet wird wenn bits beim Entschlüsseln mithilfe von CFB fehlen; https://en.wikipedia.org/wiki/Block_cip ... _.28CFB.29)

Kann das bitte ein Veranstalter bestätigen?

[jens1234]

müssen wir nicht auch dem dem m ein padding hinzufügen( falls das oben richtig ist)? da beim entschlüsseln ja f(k,m) gebildet werden muss und m die Länge 8 hat?