Diskussion:Cipher Block Chaining Mode

message: "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)
replies: text: 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)
thread_title:  Übertragen von IV 

message: 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)
replies: text: 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)
replies: text: Ich meinte ja die Verschlüsselung! :-) --RokerHRO 13:12, 8. Aug. 2007 (CEST)
thread_title:  Parallelität 

message: 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)
thread_title:  "Generell sollte ein Blockchiffre immer im CBC-Modus betrieben werden - Ausnahmen sollten gut begründet sein." 

message: 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  und  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)
thread_title: Bildbeschreibung fehlt bei ''<nowiki>[[Bild:Cbc encryption.png]] und [[Bild:Cbc decryption.png]]</nowiki>'' 

message: 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)
replies: text: Zur Vereinfachung wird als Codierfunktion + (plus) verwendet (dementsprechend als Decodierfunktion - (minus)) und Überträge mitgezogen...--Flegmon 19:21, 4. Jul. 2010 (CEST)
thread_title:  Fehler im Beispiel 

message: 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.  [http://www.heise.de/security/meldung/Tool-knackt-verschluesselte-Sitzungsdaten-1017468.html Padding Oracle Exploitation Tool (Poet) [http://www.heise.de/newsticker/meldung/Cookies-von-ASP-NET-Servern-knackbar-1078400.html Cookies von ASP.NET-Servern knackbar
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)
replies: text: siehe www.ay2.org/downloads/FSE2005.pdf die letzten zwei Folien--Flegmon 12:31, 15. Sep. 2010 (CEST)
thread_title: Padding Oracle

message: 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.  [http://www.heise.de/security/meldung/Tool-knackt-verschluesselte-Sitzungsdaten-1017468.html Padding Oracle Exploitation Tool (Poet) [http://www.heise.de/newsticker/meldung/Cookies-von-ASP-NET-Servern-knackbar-1078400.html Cookies von ASP.NET-Servern knackbar
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)
replies: text: siehe www.ay2.org/downloads/FSE2005.pdf die letzten zwei Folien--Flegmon 12:31, 15. Sep. 2010 (CEST)
thread_title:  Anfälligkeit für Angriff mittels "Padding Oracle Exploitation" 

message: 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)
thread_title:  CBC-MAC von leerer Nachricht? 

message: 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)
thread_title:  Übliches Padding bei CBC-MAC?