Diskussion:Cipher Block Chaining Mode

Schaden durch beschädigte Blöcke ist viel größer

wenn in einem Block auch nur ein Bit kippt, so ist nicht nur dieser und der darauf folgende Block unterschiedlich, sondern alle darauf folgenden Blöcke sind komplett verschieden, da sie alle von dem geänderten Block abhängen. CBC eignet sich daher nicht für unzuverlässige Übertragungskanäle, da bereits ein einziges gekipptes Bit ausreicht, um alle darauf folgenden Daten nicht wiederherstellbar sind. --RokerHRO 11:38, 7. Sep 2005 (CEST)

Das ist so schon richtig, wie im Artikel steht beeinflußt ein Block nicht alle nachfolgenden Blöcke sondern nur die beiden nächsten. Der IV für den nächsten Block ist nicht der Klar-Text (das ist ein anderer Modus) sondern der verschlüsselte Text, der ja zwei Blöcke weiter nicht beeinflußt wurde, von dem gekippten bit. 84.148.93.212 SJW

Kann die Aussage so auch nicht nachvollziehen, das sollte im Artikel ausführlicher erklärt werden. Wenn Block B von A abhängt, und Block C von B, dann hängt doch auch Block C von A ab. Auch die Grafik spiegelt das wieder. Dieser Post kommt zu derselben Aussage: https://searchsecurity.techtarget.com/definition/cipher-block-chaining

Selbst wenn wir annehmen ein Block wäre z.B. nur 16 Bytes, dann ist ein Schaden von 256+ Bits deutlich heftiger als ein gekipptes Bit - Das kann auch bei heutigen Festplatten leicht zum tragen kommen, die Fehlerrate ist im Verhältnis zur Mediengröße nämlich alles andere als klein. Daher sollte man diesen Nachteil doch deutlich als solchen vermerken. --Darky77 01:55, 14. Okt. 2008 (CEST)

Dieser Nachteil ist nur eine Folge einer schlechten Implementierung. Denn eine Fehlerkorrektur (ECC) (ggf Teil der Kanalcodierung) für die magnetische Aufzeichnung auf der Platte sollte beim Lesen vor der Entschlüssung erfolgen, bzw. beim Schreiben nach der Verschlüsselung.--wdwd 09:39, 14. Okt. 2008 (CEST)

Übertragen von IV

"Wenn man diesen Initialisierungsvektor geheim überträgt, trägt es nicht zur Sicherheit des Algorithmus bei."

Ist undeutlich formuliert finde ich. Ist das wirklich so gemeint? AFAIK ist das Übertragen des IV notwendig und kein Sicherheitsverlust.

Es gibt auch eine Block-Modus(OFB denke ich) bei dem der Orginaltext der IV des nächsten Blockes ist, mit Ausnahme des ersten Blockes. Bei diesem Modus ist der IV sehr wichtig für das Dekodieren der nachfolgenden Blöcke. Beim CBC ist es das nicht. --SJW 217.5.205.2 21:40, 15. Mai 2007 (CEST)

Der IV muss einem Angreifer nicht verborgen werden und kann als Klartext zwischen Sender und Empfänger übertragen werden, da sich aus der Kenntniss des IV beim CBF kein wesentlicher Vorteil für einen Angreifer ergibt. Unabhängig vom verwendeten Blockmodus ist zunächst erst einmal wichtig dass die eingesetzte Blockchiffre sicher ist und dass der Angreifer für die Chiffrierung benuzten Schlüssel nicht erhält und auch nicht, z.B. durch probieren oder berechnen, erhalten kann. Sollte er den Schlüssel erhalten, so würde ihm der unbekannte IV beim CBF lediglich davon abhalten den ersten Schlüsseltextblock zu entschlüsseln. Klartextblöcke werden meines Wissens in keinem der Blockmodi als IV verwendet. OFB verwendet als IV immer den durch die Chiffrierungsoperation der verwendeten Blockchiffre zuletzt erhaltenen Wert. Ob sich bei OFB ein zusätzlicher Sicherheitsgewinn durch die Geheimhaltung des IV ergeben würde kann ich jetzt aber leider auch nicht genau sagen. --87.171.87.95 16:02, 26. Sep. 2008 (CEST)

Parallelität

Gibt es eine Möglichkeit, die Sachen parallel zu bearbeiten?

Nein, da ein Block ja von dem zuvor verschlüsselten Block abhängt. Diese fehlende Parallelisierbarkeit ist einer der Nachteile von CBC. --RokerHRO 19:12, 17. Mai 2007 (CEST)

Wiederum irrt RokerHRO! Aus dem selben, genannten Grund ist Parallelisierung bei der Entschlüsselung möglich (nicht jedoch bei der Verschlüsselung). --84.152.253.148 12:38, 8. Aug. 2007 (CEST)

Ich meinte ja die Verschlüsselung! :-) --RokerHRO 13:12, 8. Aug. 2007 (CEST)

"Generell sollte ein Blockchiffre immer im CBC-Modus betrieben werden - Ausnahmen sollten gut begründet sein."

Ist das objektiv? Ist nicht XTS viel schneller uns sicherer solange man den gleichen IV für nicht mehr als 1TB an Daten verwendet (src: en.wikipedia)

vor allem ist es nicht belegt, ich habe die aussage daher entfernt. (auch angesichts von padding-oracle angriffen) --Mario d 21:10, 27. Okt. 2011 (CEST)

Bildbeschreibung fehlt bei [[Bild:Cbc encryption.png]] und [[Bild:Cbc decryption.png]]

Der Artikel enthält ein Bild, dem eine Bildbeschreibung fehlt, überprüfe bitte, ob es sinnvoll ist, diese zu ergänzen. Gerade für blinde Benutzer ist diese Information sehr wichtig. Wenn du dich auskennst, dann statte bitte das Bild mit einer aussagekräftigen Bildbeschreibung aus. Suche dazu nach der Textstelle [[Bild:Cbc encryption.png]] und [[Bild:Cbc decryption.png]] und ergänze sie.

Wenn du eine fehlende Bildbeschreibung ergänzen willst, kannst du im Zuge der Bearbeitung folgende Punkte prüfen:

• Namensraum Datei: Bilder sollte im Namensraum Datei liegen. Bitte ändere die alten Bezeichnungen Bild: und Image: in Datei:.
• Skalierung: Außerhalb von Infoboxen sollten keine festen Bildbreiten (zum Beispiel 100px) verwendet werden. Für den Fließtext im Artikelnamensraum gibt es Thumbnails in Verbindung mit der automatischen Skalierung. Um ein Bild/eine Grafik in besonderen Fällen dennoch größer oder kleiner darzustellen, kann der „upright“-Parameter verwendet werden. Damit erfolgt eine prozentuale Skalierung, die sich an den Benutzereinstellungen orientiert. --SpBot 21:50, 1. Mär. 2009 (CET)

Fehler im Beispiel

01 + 11 ist nicht 100, sondern 10, da es sich nicht um eine Addition sondern um eine XOR-Verknüpfung handelt.--87.78.203.87 18:05, 4. Jul. 2010 (CEST)

Zur Vereinfachung wird als Codierfunktion + (plus) verwendet (dementsprechend als Decodierfunktion - (minus)) und Überträge mitgezogen...--Flegmon 19:21, 4. Jul. 2010 (CEST)

Padding Oracle

Ich hab mal diesen Absatz entfernt:

Anfälligkeit für Angriff mittels "Padding Oracle Exploitation"

Der CBC Betriebsmodus muss nach aktuellen Kenntnisstand als nicht mehr zuverlässig bzw. sicher eingestuft werden. Mittels "Padding Oracle Exploitation" ist das wiederherstellen des Geheimtextes ohne Kenntnis des Schlüssels in "sinnvoller" Zeit möglich.

Diese Aussage ist nämlich so falsch, CBC ist nur unsicher wenn es nicht ordentlich implementiert ist. Und zwar in der Form, dass ein Padding Oracle vorhanden ist. Ohne Padding Oracle ist CBC weiterhin sicher (Wenn nicht hätt ich sehr gerne eine Quelle dafür :). Ich hab mich leider mit dem Padding Oracle noch nicht genügend beschäftigt um den Absatz vernünftig umzuformulieren. Aber wenn es in der Deutschen Wikipedia einen Artikel über das Padding Oracle gibt, wäre eine Erwähnung dass viele Implementationen dafür anfällig sind sicher sinvoll.--Flegmon 12:24, 15. Sep. 2010 (CEST)

siehe www.ay2.org/downloads/FSE2005.pdf die letzten zwei Folien--Flegmon 12:31, 15. Sep. 2010 (CEST)

CBC-MAC von leerer Nachricht?

Was ist der CBC-MAC von einer leeren Nachricht (Länge 0)? Nach der existierenden Beschreibung ist das nicht definiert. Wenn es definiert ist (CBC_MAC == IV?) wäre diese Definition nützlich. --Overmann (Diskussion) 17:27, 2. Feb. 2015 (CET)

Übliches Padding bei CBC-MAC?

CBC ist ein Block Modus und MACs sind immer für allgemeine Nachrichten mit beliebiger Länge. Daher wäre es nützlich, zu erwähnen, welches padding üblicherweise bei gängigen CBC-MAC Varianten benutzt wird (evtl. zusammen mit dem jeweiligen IV). CCM benutzt zero-padding. Welche anderen Varianten von CBC-MAC sind üblich? --Overmann (Diskussion) 17:39, 2. Feb. 2015 (CET)