Diskussion:Blockverschlüsselung

Textspende von Benutzer:Korelstar -- fab 22:22, 5. Jan 2004 (CET)

Overhead bei Blockgröße

(bei einer Blockgröße von 128 Bit werden die verschlüsselten Daten somit maximal 16 Byte größer als der Klartext).

Das ist falsch!!

Es gilt:

bs: Blockgröße c: Geheimtext m: Klartext

size(c) < size(m) + bs !!!!

Eine richtige Formulierung ist hier schwer zu finden, mögliche Kandidaten wie

...somit maximal 15 Byte größer als der Klartext). ...somit maximal 12 Byte größer als der Klartext). (drei 32 Bit Wörter)

stimmen auch nur unter gewissen Annahmen.

Vielleicht so:

...somit maximal 127 Bit größer als der Klartext).

???

Hinweis: Es gibt eine Technik für Blockchiffen, die nennt sich ciphertext stealing. Bei dieser ist der Chiffretext genauso lang wie der Klartext. Funktioniert aber nur bei mindestens 2 Blöcken. --Mojo1442 21:28, 2. Sep. 2009 (CEST)

Kommt mir die Frage in den Sinn, was mit Padding ist? Beispiel: Klartext exakt 256 Bit. Würde theoretisch genau aufgehen (2 Blöcke). Aber das Padding muss ja präfixfrei sein, damit man es immer rückgängig machen kann. Also muss ich ja z.B. wenn ich mit „1000…“ padde – schönes Wort – immer mindestens die „1“ anhängen. Würden also aus den 256 Bits schonmal 257 werden (neuer Block) und um den Block dann mit Nullen aufzufüllen eben 384 Bits. Der Chiffretext ist dann auch 384 Bits lang. Also ist es sogar: ${\text{size}}(c)\leq {\text{size}}(m)+bs+1$. Oder irre ich mich da? --Bananenfalter 14:49, 7. Aug. 2010 (CEST)

Relevanz der Frage

Die Frage nach nach dem Overhead durch das Padding ist nach meiner Meinung völlig belanglos. Bei dem üblichen Paddingverfahren (Anhängen von 1000...) ist maximal ein voller Block (8 Byte für 3DES und IDEA und 16 Byte = 128 Bit für AES). Aber was ist die im Vergleich zu der pro Sekunde per DSL übertragenen Daten bzw. der Größe einer Festplatte ?

Hast natürlich recht. Habe das einfach mal angepasst. Ist zwar auch noch nicht so glücklich; wem was besseres einfällt, möge es korrigieren. Übrigens wäre es schön, wenn du Kommentare in der Diskussion immer mit --~~~~ unterschreibst. --Korelstar 20:59, 6. Okt 2004 (CEST)

Im Großen und Ganzen habt ihr recht. Aber es gibt spezielle Anwendungen wo es auf jedes Byte ankommt. Z.B. bei Kommunikation von Embedded Systems z.B. innerhalb der Automobil-Elektronik. Ein anderes Beispiel ist ein Ticket auf Papier mit kryptographischem Code (z.B. bei der Bahn), auch hier zählt jedes Zeichen, das der Kontrolleur eintippen muss (wenn man keinen Barcode-Scanner nutzen kann). Für beide Fälle hatte ich schon konkrete Anfragen von Kunden wie man hier die Ciphertexte möglichst kurz halten kann. --Mojo1442+

Auffüllen mit Zufallsdaten?

Der letzte Block wird nicht nur mit Zufallsdaten aufgefüllt, denn im letzten Block muss auch kodiert werden, wie lang der letzte Block ursprünglich war. Bei 128-Bit und beim Arbeiten mit Bytes als kleinster Einheit sind 4 Bit für das Speichern der Länge des letzten Blocks notwendig (aufgerundet 1 Byte). Eine Sonderbehandlung muss stattfinden, wenn der Block bereits aus 16 Bytes besteht, denn dann gibt es keinen Platz im Block für dieses benötigte zusätzliche Byte. Sinnvollerweise bringt man das Byte am Ende des Blocks unter und füllt die dazwischenliegenden ungenutzten Bytes mit Zufallsdaten auf.

Mathe

"Da die Schlüssellänge typischer Blockchiffren weit geringer als $\log _{2}(2^{n}!)$ ist, wird durch die Gesamtheit aller Schlüssel nur ein kleiner Teil aller möglichen Abbildungen erfasst. "

sind wirklich alle diese Abbildungen bijektiv??

Logik der Sprache

Ich wollte es nicht gleich ändern: Aber meiner Meinung nach müsste im ersten Absatz statt "Schlüssellänge moderner Verfahren sind 128, 168, 192 und 256 Bit" anstelle des und ein oder, sprich "[...] sind 128, 168, 192 oder 256 Bit". Schließlich kann man ja nur eine Länge gleichzeitig nutzen. --Nurnware 23:07, 26. Mär. 2009 (CET)

Hinweis auf schwammige Definition

Der Unterschied zwischen Block und Stromchiffren ist ja eigentlich nur das Eingangsalphabet. So kann theoretisch eine Blockchiffre als Stromchiffre eines Eingangsalphabetes mit einem Alphabet von 2^0..2^n-1, wobei n die Blockgroesse darstellt, gesehen werden. 141.76.8.64 11:48, 31. Aug. 2009 (CEST)

Das könnte man zwar aus dem reichlich besch-eidenen Artikel herauslesen, ist aber leider nicht korrekt. So lässt sich das Eingangsalphabet (Wortbreite) einer Stromchiffre beispielsweise durch Parallelisierung beliebig erweitern, allerdings erhält man dann keinen Blockchiffre, sondern allenfalls ein Array von Stromchiffren. Dadurch lässt sich zwar die Performance steigern, aber aus mathematischer, bzw. kryptologischer Sicht ist´s Jacke wie Hose, ob man einen Datenblock am Stück oder häppchenweise (Als Strom nach vorheriger Serialisierung) durch einen Stromchiffre jagt. Der Chiffre bleibt nämlich unabhängig von der konkreten Implementation derselbe.

Der Unterschied zwischen Block- und Stromchiffren ist fundamentaler Natur, Blockchiffren zeichnen sich in der Regel durch Diffusion (Kryptologie) aus, Stromchiffre prinzipbedingt nicht.

Ein Stromchiffre verknüpft jeweils ein Zeichen des Klartextes mit einem oder mehreren Zeichen des Schlüssels. Ändert sich ein Zeichen im Klartext, so ändert sich auch nur ein Zeichen im Geheimtext und umgekehrt.

Ein Blockchiffre hingegen verknüpft nicht nur die einzelnen Zeichen im Klartextblock irgendwie mit dem Schlüsselblock sondern zusätzlich mit dem Klartextblock, so das die Änderung eines Klartextzeichens die Änderung mehrerer Zeichen des Geheimtextes nach sich zieht. Idealerweise führt die Veränderung eines Klartextzeichens dazu, daß sich jedes Geheimtextzeichen mit einer Wahrscheinlichkeit von 50% ändert und umgekehrt, bzw. die Veränderung eines Zeichens im Klartextblock ändert im Mittel 50% des Geheimtextblocks. Grüße -- sambalolec 11:52, 23. Sep. 2009 (CEST)

Änderungen vom 23. Januar 2010, 19:37 Uhr

http://de.wikipedia.org/w/index.php?title=Blockverschl%C3%BCsselung&curid=94373&diff=69707394&oldid=69594766&rcid=69540951

Es wurden Textstellen wortwörtlich aus der Quelle entnommen. Gibt es dafür eine Erlaubnis der Autoren? Wenn nicht müssten die Stellen aus Urheberrechtsgründen umformuliert oder entfernt werden.--Schönen Gruß "Wohingenau" 20:02, 23. Jan. 2010 (CET)

Habe die Textstellen neu geschrieben, danke für den Hinweis. Omikronn 01:35, 25. Jan. 2010 (CET)

habe diese Version gelöscht. --tsor 07:58, 7. Feb. 2010 (CET)

keine monoalphabetische substitution

eine blockchiffre würde ich aus folgenden gründen nicht als monoalphabetische substitution (msub) bezeichnen:

1. als msub werden üblicherweise historische verfahren bezeichnet, blockchiffren gibt es erst seit dem 20. jahrhundert.
2. bei einer msub ist der schlüssel das geheimalphabet (-> schlüsselalphabet). bei einer blockchiffre ist der schlüssel (nach der expansion) ein parameter der rundenfunktion.
3. msubs operieren auf alphabeten, blockchiffren (üblicherweise) auf bitfolgen.
4. aus diesem grund gibt es viele eigenschaften von blockchiffren, die nicht sinnvoll aus msubs angewendet werden können (bspw. gute diffusion und konfusion)

sowohl msubs als auch blockchiffren sind (in allen praktischen fällen) - für einen festen schlüssel - permutationen. es sind aber jeweils unterschiedliche spezialfälle von permutationen. es ist wenig sinnvoll, msubs mit (familien von) permutationen gleichzusetzen, denn dann könnte man sich den begriff auch sparen. ich sehe nicht, dass der inhalt des satzes "blockchiffren sind msubs" über den von "blockchiffren sind familien von permutationen" hinausgeht. damit wird also nichts erhellt, sondern der leser eher verwirrt (aus den o. g. gründen). solange es keinen beleg in der wissenschaftlichen literatur gibt, der die bezeichnung von blockchiffren als msubs stützt, würde ich das im artikel daher nicht erwähnen. --Mario d 11:19, 5. Jan. 2017 (CET)

Du verwechselst da was. Beleg könnte ich auch liefern, schließlich habe ich meine Bücher noch. Aber eigentlich halte ich mich bei Themen, die ich jahrelang beruflich ausgeübt habe (und für die ich gut bezahlt worden bin), eher etwas zurück. Man wird zu schnell ungeduldig, weil man die Verständnisprobleme von Nicht-Profis bzw. oder Studis als anstrengend empfindet. Das war gestern ein nächtlicher Ausflug von mir in die Kryptographie, den ich nicht weiter ausdehnen will. Ich war einfach nicht müde, habe herumgelesen und hier und da Kleinigkeiten angepackt. Wenn du also jetzt verwirrend findest, dass Blockverschlüsselungen auf monoalphabetische Substitutionen zurückgreifen, bitte sehr. Ich werde das im Artikel nicht detaillierter erklären. Aber es ist so, glaub mir's. WIr lagen vor Madagaskar (Diskussion) 11:40, 5. Jan. 2017 (CET)

schwammige Formulierung

Am Ende des ersten Absatzes werden Verschlüsselungen mit langem Schlüssel als "praktisch unmöglich" zu entschlüsseln bezeichnet (ohne den Schlüssel). Diese Formulierung ist sehr schwammig, da der Ausdruck praktisch (auf die Praxis bezogen) in diesem Fall nicht näher definiert wurde und daher nicht ersichtlich ist von welcher Praxis hier gesprochen wird (Rechenleistung). So kann die Bandbreite möglicherweise gemeinter Hardware von einem Taschenrechner von vor 20 Jahren bis zu einem Quantencomputer reichen. (nicht signierter Beitrag von 193.18.240.18 (Diskussion) 08:19, 27. Jan. 2020 (CET))