Seite 1 von 1

CTR Mode

Verfasst: 28. Dez 2014 11:14
von 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?

Re: CTR Mode

Verfasst: 3. Jan 2015 11:56
von 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...

Re: CTR Mode

Verfasst: 4. Jan 2015 13:01
von jens1234
weiß jemand ob es in der kommenden Woche Sprechstunden gibt?

Re: CTR Mode

Verfasst: 4. Jan 2015 15:15
von 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…

Re: CTR Mode

Verfasst: 4. Jan 2015 18:34
von 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

Re: CTR Mode

Verfasst: 4. Jan 2015 19:04
von hstr
D.h. c_1 = 001 XOR 100 im obigen Beispiel?

Re: CTR Mode

Verfasst: 4. Jan 2015 19:15
von mmi1991
R_Egert hat geschrieben: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?

Re: CTR Mode

Verfasst: 4. Jan 2015 19:54
von 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

Re: CTR Mode

Verfasst: 6. Jan 2015 09:41
von hstr
R_Egert hat geschrieben:
D.h. c_1 = 001 XOR 100 im obigen Beispiel?
Sollte so passen.
Rolf
Ok, Danke.
mmi1991 hat geschrieben: 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?

Re: CTR Mode

Verfasst: 6. Jan 2015 11:43
von 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?