Diskussion:One-Time-Pad/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:One-Time-Pad/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:One-Time-Pad/Archiv/1#Thema_1

Ganz alter Kram

Nachdem ich den Artikel komplett überarbeitet habe, ist es vielleicht sinnvoll, die vergangenen Diskussionen zu den Akten zu legen. --OS 08:22, 6. Okt 2006 (CEST)

ergaenzung: siehe diff. -- seth 23:49, 17. Feb. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Brute Force

Vielen Dank für die Überarbeitung. Vielleicht solltest du den Hinweis auf Brute Force wieder mit hineinnehmen. Denn diese Frage taucht immer wieder auf. Das Beispiel hast du hinausgeworfen; war es nicht genügend anschaulich? Anton 02:12, 7. Okt 2006 (CEST)

Hallo Anton, inzwischen habe ich entdeckt, was du vermutlich meinst. Es ist wohl das folgende Beispiel, das du ansprichst und das in der ursprünglichen Fassung des Artikels enthalten war:

Brute-Force Entschlüsselung eines One-Time-Pad-Verschlüsselten Textes Zur Chiffre lassen sich beliebige Klartexte finden. Es ist nicht möglich zu entscheiden, welches der richtige Klartext ist. Chiffre: NMSINUDZDX Schlüssel1: BEZPJMSFQR Klartext: MITTEILUNG   Chiffre: NMSINUDZDX Schlüssel2: JEFMJMLFQR Klartext: EINWEISUNG

Richtig, ich habe es (wie vieles andere auch) hinausgeworfen. Es passte nach der Überarbeitung nicht mehr so gut (speziell ist seine Länge nicht 21). Sattdessen gibt es nun den Passus mit dem Pseudoklartext WIKIPEDIAFINDENWIRGUT.

Sorry, das Beispiel ist doch prima, um zu verstehen, warum das OTP wirklich nicht zu knacken ist, nicht einmal mit dem schnellsten Supercomputer und Bruteforce. Die Länge ist im Prinzip völlig egal, aber mit einer überschaubaren Zahl von 12 Zeichen wird die Sache schön anschaulich. Mit 12 Zeichen wäre es noch möglich alle denkbaren Schlüssel 26¹² mit einem Rechner zu probieren. Meist ergibt die Entschlüsselung Müll, manchmal für den Schlüssel BEZPJMSFQR oder den Schlüssel JEFMJMLFQR auch was sinnvolles wie MITTEILUNG oder EINWEISUNG. Tatsächlich gibt es für jeden denkbaren Klartext wie etwa MITTEILUNG einen und nur einen Schlüssel, in diesem Fall BEZPJMSFQR, der aus der vorgegebenen Chiffre, hier NMSINUDZDX den Klartext MITTEILUNG oder EINWEISUNG oder auch ABCDEFGHIJKL ergibt. Damit ist der Code-Knacker aber im Grunde genau so schlau wie zuvor. Er weiß nur, das der Klartext aus 12 Buchstaben besteht und sonst gar nichts. --88.68.106.141 15:05, 17. Dez. 2008 (CET)

Der im Ergebnis erhaltene Geheimtext G ist von einem Zufallstext nicht zu unterscheiden und kann prinzipiell mit keiner noch so gearteten kryptanalytischen Angriffsmethode (weder jetzt noch in Zukunft) entziffert werden. Allein die Kenntnis des Schlüssels S erlaubt es, aus dem Geheimtext G wieder den Klartext K zu gewinnen. Ohne den Schlüssel kann man prinzipiell alle denkbaren und mehr oder weniger sinnvollen Buchstabenkombinationen aus 21 Buchstaben „konstruieren“. Theoretisch könnte ein Angreifer dies probieren. Er würde so eine Unmenge an Sätzen erhalten, die in beliebigen Sprachen beliebige Informationen verkünden würden, beispielsweise K' = WIKIPEDIAFINDENWIRGUT mit dem dazu „passenden“ Schlüssel, der der Differenz zwischen Geheimtext G und dem konstruierten Pseudo-Klartext K' entspricht (S' = G - K'): S' = AEOUQXOFCBJQSJLIZXLHV Dieser Schlüssel S' erfüllt die Bedingung, dass die buchstabenweise Summe von ihm mit dem oben erzeugten (falschen) Klartext K' genau den gleichen Geheimtext ergibt wie die Summe aus dem echten - aber dem Angreifer unbekannten - Schlüssel S mit dem echten - und dem Angreifer ebenso unbekannten - Klartext K. So kann der Angreifer eine unübersehbare Fülle von denkbaren Klartext-Schlüsselpaaren konstruieren, die in (buchstabenweiser) Summe alle den gleichen echten Geheimtext ergeben. Er hat jedoch keine Möglichkeit, daraus auf den echten Klartext zurückzuschließen. Solange ihm der Schlüssel nicht in die Hände fällt, bleibt der Klartext auf ewig geschützt.

--OS 08:43, 9. Okt. 2006 (CEST)

OK, habe ich verstanden. Satz zu Brute Force habe ich in die Einleitung geschrieben. Anton 22:07, 9. Okt. 2006 (CEST)

Freut mich, jedoch habe ich aus "dramaturgischen" Gründen deinen Hinweis lieber ins Kapitel "Angriffsmöglichkeiten" verschoben. In der Einleitung ist es nach meiner Einschätzung etwas zu früh. Wie ich hoffe, bist du einverstanden. --OS 09:32, 10. Okt. 2006 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Beweisbare Sicherheit

danke OS für deine überarbeitung, liest sich gut. eine kleinigkeit: mathematisch beweisbar sicher finde ich eine ungünstige formulierung. es assoziiert, dass andere verfahren nicht mathematisch sicher sind, obwohl sie lediglich schwächeren prinzipien genügen. diesbzgl auch mal die frage/bitte an anton zu einer allgemein akzeptierten klassifizierung. mein vorschlag dazu (was ich aus einigen büchern/skripten habe):

• informationstheoretische sicherheit (z.b. one-time-pad)
• kryptographisch stark (z.b. vignere verfahren (auch pseudo-one-time-pad), gmr)
• wohluntersucht = anscheinend sicher aber z.z. kein sicherheitsbeweis (z.b. rsa)

gruss --Murkel ^(anmurkeln) 22:09, 14. Okt. 2006 (CEST)

Hallo Murkel, danke für dein Lob und auch deine Kritik! Deinen Hinweis von oben habe ich hierhin in ein Extra-Kapitel verschoben. Dann stimmt die Chronologie der Einträge und es bleibt thematisch übersichtlicher, falls sich auch andere an unserer Diskussion beteiligen wollen. Wie ich glaube, sind wir uns einig, dass das OTP das einzige kryptographische Verfahren ist, dass mit dem Prädikat mathematisch beweisbar sicher (nach Shannon) belegt werden darf. Aber dennoch ist die Formulierung, speziell im einleitenden Abschnitt des Lemmas vielleicht ungünstig, weil sie möglicherweise beim Leser falsche Assoziationen wecken könnte, nämlich, dass die anderen Verschlüsselungsmethoden völlig unsicher seien. Dennoch gilt, dass alle anderen Verfahren tatsächlich nicht mathematisch beweisbar sicher sind, auch wenn einige bisher (öffentlich) nicht gebrochen werden konnten. Aber wie soll man es besser formulieren, ohne diesen wichtigen Kern der Aussage zu verwässern? Hast du einen Vorschlag? Zu deinen Klassifizierungen: Das Vigenere-Verfahren als „kryptographisch stark“ zu bezeichnen, finde ich nicht richtig. Wenn auch diese Methode vor Jahrhunderten als „le chiffre indechiffrable“ („die unentzifferbare Chiffre“) galt, ist sie dies spätestens seit Kasiski nicht mehr. Aus heutiger Sicht, ist das Vigenere-Verfahren eine der am leichtesten zu brechenden Methoden überhaupt. Übrigens, was ist denn das Pseudo-One-Time-Pad? --OS 07:27, 16. Okt. 2006 (CEST)

shannon bezeichnet das was du mit mathematisch beweisbar sicher definierst als ideale konzelation. das otp ist so einfach in seiner beschreibung, dass kein anderes verfahren mit gleichen sicherheitseigenschaften nötig ist. mein punkt ist, dass es auch andere verfahren gibt, die (hier nicht im sinne von shannon) mathematisch beweisbar sicher sind. es werden annahmen getätigt (z.b. faktorisierungs-, quadratische reste- oder diskrete logarhitmusannahme) über diesen die sicherheit bewiesen wird. so beim gmr oder dem bbs-generator. solche systeme sind dann kryptographisch stark, eben weil sie (zwar nur unter annahmen) bewiesen sicher sind. RSA und DES sind (nur) wohluntersucht, da eben kein sicherheitsbeweis (bis jetzt) vorhanden ist.

als vorschlag für die einleitung: das otp garantiert die höchste erreichbare sicherheit. es gibt selbst theoretisch keine bessere strategie als pures raten. (oder so ähnlich)

noch eine hübsche formulierung: hinter jedem schlüsseltext verbirgt sich jeder mögliche klartext mit gleicher wahrscheinlichkeit.

zum pseudo-one-time-pad (die idee stammt von vignere, daher die bezeichnung vignere verfahren). man nehme einen kryptographisch starken! pseudozufallsbitfolgengenerator (PZG), um eine „zufallszahl“ (als chiffrierschlüssel) zu generieren. statt nun wie beim otp den langen schlüssel verteilen zu müssen, werden die startparamater des pzg's geheim verteilt. so kann der empfänger seinen pzg mit den parametern starten um so den schlüssel fürs dekodieren erzeugen.

gruss --Murkel ^(anmurkeln) 22:29, 18. Okt. 2006 (CEST)

Hallo Murkel, danke für deine Antwort! Ich widerspreche nur ungerne, weil ich deine Erläuterungen schätze, aber ich bin nicht ganz deiner Meinung: Es sind mir tatsächlich keine anderen Verfahren außer dem OTP bekannt, die beweisbar sicher sind! Selbstverständlich gibt es eine Reihe von sehr guten Verfahren, von denen du einige ansprichst, und die man heutzutage mit dem Adjektiv „kryptographisch stark“ belegt. Ob sie das wirklich sind, lässt sich nach meiner Ansicht nicht endgültig beweisen und das Adjektiv wird man vielleicht in Zukunft revidieren müssen, falls versteckte Schwächen der Verfahren oder neue verbesserte Angriffsmethoden entdeckt werden. Auch für die von dir als Beispiele genannten Einwegfunktionen, für die man (momentan) keine einfache Umkehrung kennt, hat die Zukunft möglicherweise noch einige Überraschungen parat. Deshalb würde ich in diesem Zusammenhang nicht von „beweisbarer Sicherheit“ sprechen. Du selbst erwähnst Voraussetzungen oder Annahmen, also Einschränkungen. Deshalb würde ich die anderen Verfahren auch nicht auf eine Stufe mit dem OTP stellen. Habe inzwischen den Artikel von Claude Shannon, auf den du dich vermutlich mit deiner Eingangsbemerkung beziehst, mit in das Literaturverzeichnis aufgenommen. (Communication Theory of Secrecy Systems. Bell System Technical Journal, Vol 28, 1949 (Oktober), pp. 656-715 (PDF-Datei zum Herunterladen)) Kannst du mir vielleicht erklären, an welcher Stelle genau er den von dir zitierten Begriff „ideale Konzelation“ einführt? Zum „Pseudo-One-Time-Pad“: Dass die Idee dazu von Vigenere stammen soll, wie du schreibst, kann ich nicht glauben! Klar ist, Vigenere hat basierend auf der Tabula recta sein nach ihm benanntes Tableau zur polyalphabetischen Verschlüsselung vorgeschlagen und zwar mit einem Schlüsselwort wie PARIS oder ähnlich, das periodisch wiederholt wird - jedoch sicher nicht mit einem Einmalschlüssel! Denn sonst hätte er ja die Erfindung des OTP im 20. Jahrhundert vorweggenommen. Und „Pseudozufallsbitfolgengeneratoren“, die du erwähnst, kannte Vigenere sicher auch nicht. Im Übrigen sind diese auch nicht beweisbar sicher - im Gegenteil! Klar ist auch, dass manche Leute völlig überflüssigerweise das OTP-Verfahren mit einem Vigenere-Quadrat kombinieren. Aber das ist nur eine der vielen möglichen Varianten des OTP und dies würde ich nicht mit einem Extra-Namen wie „Pseudo-One-Time-Pad“ belegen. Wer hat denn den von dir zitierten Namen so eingeführt? Gruß --OS 07:19, 19. Okt. 2006 (CEST)

was heißt mathematisch beweisbar umgangssprachlich? doch sicherlich nur, dass mathematik zur beweisführung genutzt wird. somit ist jedes system, dessen sicherheitsbeweis auf mathematik beruht, mathematisch beweisbar sicher. verstehst du jetzt meinen punkt? ich gebe dir recht, das ein sicherheitsbeweis, der sich auf annahmen stützt, nicht mit einem im sinne der von shannon beschriebenen konzelation zu vergleichen ist. trotzdem ist es ein mathematisch geführter sicherheitsbeweis. aufgrund dieser schwammigen begrifflichen situation hatte ich zu beginn der diskussion ja zu einer systematisierung aufgerufen.

nun zu claude shannon, wo ich was durcheinander gebracht habe. als perfekte konzelation bezeichnet er die durch das otp gegebene sicherheit; heutzutage als informationstheoretische oder unbedingte sicherheit bezeichnet. mit idealer konzelation betitelt er eine leicht schwächere sicherheit. ein angreifer gewinnt durch schlüsselkenntnis einige information (z.b. kann er einzelne nachrichten ausschliessen) aber nicht genug, um dem schlüsseltext eindeutig einen klartext zuzuordnen.

stichwort vignere, dazu zitiere ich mal das skript meines profs: Statt einer echten Zufallsfolge wird eine Pseudozufallsfolge bitweise modulo 2 zum Klartext addiert. Diese Idee stammt von de Vigenère (1523-1596), dem zu Ehren das Pseudo-one-time-pad manchmal Vigenère-Chiffre genannt wird. validiert habe ich diese aussage allerdings nicht. die verschiedene nomenklatur zwischen otp und pseudo-otp ist afaik berechtigt. schon punkto sicherheit - informationstheoretisch einerseits, kryptographisch stark andererseits. der aufwand ist auch recht verschieden - lange schlüssel beim otp, kurzer startwert beim pseudo-otp.

noch ein paar anmerkungen zu den sicherheitsklassen. informationstheoretische sicherheit bedeutet absolute sicherheit (bei korrekter benutzung). ein angreifer könnte also zeit, rechenpower und geld ohne ende haben, das verfahren ist sicher für die unendlichkeit. bei kryptographisch stark hängt die messlatte tiefer. ein angreifer mit unendlichen ressourcen bricht ein solches verfahren; z.b. diffie-hellmann. hier kann er diskrete logarithmen ziehen.

gruß --Murkel ^(anmurkeln) 14:29, 24. Okt. 2006 (CEST)

Habe die Formulierung „mathematisch beweisbar sicher“ in „informationstheoretisch sicher“ geändert. Der zitierten Aussage deines Profs. kann ich nicht zustimmen. Die Sicherheitsklassen sehe ich wie du! Gruß --OS 06:28, 25. Okt. 2006 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Angriffsmöglichkeiten

Bei dem Beispiel mit den zwei Nachrichten sollte noch erwähnt werden, das sich beim verwenden eines zu kurzen Schlüssels (mit Schlüsselwiederholung) das gleiche Problem ergibt. Dann hat man nochmal verdeutlicht warum der Schlüssel so lang wie die Nachricht selbst sein muss. Gruß Nevfennas 17:00, 2. Dez. 2006 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Speicherung auf handelsüblichen Datenträgern

Es ist nicht so einfach die Datenspuren auf den wiederverwendbaren zu beseitigen, daher sollten die Datenträger physisch zerstört werden! (nicht signierter Beitrag von 195.253.25.123 (Diskussion | Beiträge) 12:41, 8. Dez. 2006 (CET))

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Exzellenz-Kandidatur: One-Time-Pad (Archivierung Abstimmung 1. bis 21. Dezember 2006)

Diese Kandidatur läuft vom 1. Dezember bis zum 21. Dezember.

Der Artikel erklärt einen komplexen Sachverhalt sehr gut verständlich mit ausführlichen Beispielen. Auch als Einführung in das wichtige Thema Kryptologie ist er geeignet, da er die wichtigsten Kriterien zur Bewertung kryptografischer Verfahren gut darstellt. (nicht signierter Beitrag von Tvp (Diskussion | Beiträge) )

Ich muss mich ersteinmal dafür entschuldigen, dass ich den Artikel nur überflogen habe, aber wäre für den Artikel nicht erstmal eine Stufe zurückzudrehen und beim Review oder der Kandidatur zum Lesenswerten Artikel anzufangen. Rein optisch haut die Formatierung der Quellen, Zitate und vieler anderer Dinge nicht hin, so ist sie alles andere als Wikipediakonform. Genau für solche Kleinigkeiten wäre ein Review zu empfehlen. -- Haeber (Disk., Bew.); 04:54, 2. Dez. 2006 (CET)

 Oppose Die wichtigsten Aussagen sind nicht durch detaillierte Quellenangaben (Einzelnachweise) belegt und somit nur schwer nachprüfbar. Ansonsten guter Artikel, wenn auch etwas salopp. Gruß Stefanwege 15:53, 4. Dez. 2006 (CET)

• Contra: Fachlich nach meiner Beurteilung soweit korrekt, allerdings finde ich auch, dass er für "Exzellent" noch etwas reifen muss (Formatierung, Nachweise, etc.). IMHO sollte aber Lesenswert durchaus möglich sein. Was für Exzellenz meines Erachtens fehlt:
  • Ein exzellenter OTP-Artikel sollte auch zur Geschichte der Anwendung einiges mehr zu sagen haben: Eine Blüte hatte dieses Verfahren im Kalten Krieg, als die verfügbaren Rechner noch wenig leistungsfähig waren, aber gute Quellen für echt zufällige Zahlen bekannt waren (z.b. Radioaktivität). Ich erinnere mich an einen Beitrag im Spektrum der Wissenschaft, bei dem ein ehemaliger BSI-Mitarbeiter dazu einiges zu sagen hat, vielleicht lässt sich ja das auftreiben.
  • Auch bekannte Fälle, in denen das Geheimnis ausgespäht wurde, sollten erwähnt werden. Der Grund, warum es beweisbar sicher ist, könnte auch noch etwas Oma-sicherer formuliert werden, allerdings kann ich in meiner Betriebsblindheit derzeit auch keine bessere Formulierung vorschlagen.
  • Und zu guter Letzt gibt es da noch die sogenannte "Quantenkryptografie", die sich eigentlich nur mit dem sicheren Austausch von Schlüsseln befasst und meist zur Verschlüsselung auf das OTP setzt - und erst durch diese Kombination ein beweisbar beliebig sicher sein kann. --130.83.163.185 17:49, 4. Dez. 2006 (CET)

@130.83.163.185 Du meinst den Artikel von Otto Leiberich in Spektrum der Wissenschaft Dossier Kryptographie (Dossier 4/2001). Alger Hiss bzw. das VENONA-Projekt haben mit OTP zu tun. Priwo 21:03, 11. Dez. 2006 (CET)

 Oppose Aussagen, die nicht zum allgemeinen Wissenststand eines Kryptologen gehören sind nicht belegt. Mehrere Stellen könnten prägnanter formuliert werden. Das würde die Lesbarkeit erhöhen und den Text verkürzen. Über Geschichte und Anwendung ist meines Erachtens zu wenig geschrieben. Ich bezweifle, dass die zwei Absätze unter Geschichte den Großteil der verfügbaren Information abdecken. Wie schon von einem der Vorredner erwähnt fehlt auch der Hinweis auf die Quantenkryptografie. Der Bezug zur Vernam-Chiffre wird nicht hergestellt. Das reicht mal für's erste. --Squizzz 22:58, 7. Dez. 2006 (CET)

Versucht den Abschnitt "Verfahren" mal als Otto-Normalverbraucher zu lesen. Die Erklärungen sind zwar ziemlich präzise (Hut ab!) aber nicht in einfacher Sprache formuliert. --Coolbiker 20:33, 21. Feb. 2007 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Abschnitt „Prinzip“

Hallo OS, du hast zwei meiner Änderungen wieder rückgängig gemacht. Allerdings kann ich das nicht nachvollziehen. Hier meine ausführlichere Begründung.

... Damit erfüllt das Einmalschlüsselverfahren Kerckhoffs’ Prinzip ... in idealer Weise.

Der Zusatz „in idealer Weise“ ist meines Erachtens überflüssig. Da das Verfahren nicht auf der Geheimhaltung des Algorithmus beruht ist Kerckhoffs’ Prinzip erfüllt. Man kann dieses Prinzip entweder erfüllen oder nicht. Des Weiteren ist die Offenlegung des Algorithmus keine Voraussetzung für die Sicherheit des Verfahrens. Angenommen das One-Time-Pad wäre geheim, dann wäre es immer noch perfekt sicher. --Stefan Birkner 15:59, 29. Jun. 2007 (CEST)

Das ist eine sprachliche Kleinigkeit, die es nicht lohnt, dass wir uns intensiv damit befassen. So wie es war, fand ich es zwar schöner (und der Artikel stammt zu über 90 % von mir), aber wenn du „in idealer Weise“ nicht lesen willst, kann es auch weg. Bei der anderen von dir geänderten Formulierung bitte ich dich den ursprünglichen Stand so zu lassen. --OS 07:04, 2. Jul. 2007 (CEST)

Dann kläre mich bitte auf, warum die Wahrung von Kerckhoffs’ Prinzip zur Sicherheit nötig ist. Denn wenn dies nicht der Fall ist, dann ist der Satz im Artikel falsch. --Stefan Birkner 12:10, 2. Jul. 2007 (CEST)

Zur Wahrung der Sicherheit des Einmalschlüssel-Verfahrens muss erstens der Schlüssel geheim bleiben (das fordert auch Kerckhoffs’ Maxime). Außerdem muss der Einmalschlüssel zweitens unvorhersagbar zufällig sein und drittens darf er nur einmal verwendet werden! Was ist daran falsch? --OS 13:03, 2. Jul. 2007 (CEST)

Die zentrale Aussage von Kerckhoffs’ Prinzip betrifft die Offenlegung des Algorithmus und nicht die Geheimhaltung des Schlüssels. Dass der Schlüssel geheim bleiben muss ist unstrittig, jedoch nicht die Aussage von Kerckhoffs’ Prinzip. --Stefan Birkner 13:36, 2. Jul. 2007 (CEST)

Ja. du hast recht! --OS 14:14, 2. Jul. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Zufall, Texte und Wiederholung

Dein Lieblingsroman?

Wenn der Schlüssel wirklich zufällig ist, dann kann doch auch ein Text dabei rauskommen oder ein schonmal benutzer Schlüssel entstehen, was man nichtmal nachprüfen kann, da man die Alten ja vernichtet hat. Und auch die Schlüssel, die hier in dem Artikel sind, könnten entstehen. Will soll man das denn verhindern und wenn man das verhindert, dann ist es doch kein richtiger Zufall mehr. Irgendwie fehlt mir da eine Auflösung zu dem Zwiespalt. (nicht signierter Beitrag von 89.27.216.204 (Diskussion) 01:38, 9. Dez. 2007 (CET))

Es wird nichts als Schlüssel ausgeschlossen. Das heisst: Ja, es besteht eine gewisse Wahrscheinlichkeit, dass der Geheimtext nach dem Verschlüsseln immer noch sinnvoll bzw. lesbar ist. Allerdings ist die Wahrscheinlichkeit dafür nahezu null. Vielleicht kannst Du es dir so vorstellen: Kippe eine Packung Buchstabensuppe auf einen Tisch - theoretisch könnte dann genau der Text deines Lieblingsromans vor dir liegen, ist aber halt unglaublich unwahrscheinlich. Da die Anzahl der möglichen Zufallsschlüssel und damit auch die daraus resultierende Anzahl an Geheimtexten unvorstellbar schnell wächst, kann man sich auch schwer vorstellen, dass die Wahrscheinlichkeit, dass ein sinnvoller Geheimtext entsteht quasi gleich null ist. Nimmt man, wie im Artikel, nur das deutsche Alphabet zur Kodierung, hat bereits ein Klartext mit 50 Zeichen (dieser Satz ist doppelt so lang) mehr mögliche Verschlüsselungen als Atome in der Milchstraße existieren. Dass man aus der Menge dann mit einem zufälligem Ziehen genau die Handvoll "sinnvolle" Texte (das sind die, die das verraten, was ich verheimlichen will) erwischt ist praktisch unmöglich. Deshalb muss es auch nicht ausgeschlossen werden. Ich hoffe, ich konnte ein wenig zur Verständlichkeit beitragen?  — Felix Reimann 11:23, 9. Dez. 2007 (CET)

Also sind sinnvolle Texte als Schlüssel oder die Schlüssel, die hier in der Wikipedia genannt wurden, so lange gute Schlüssel, solange sie "ausersehen" (also durch den Zufall) genutzt werden?--89.27.202.109 15:52, 16. Dez. 2007 (CET)

Ja, das wären sie: ABER: Sicher, ist das OTP nur dann, wenn der Schlüssel durch einen guten Zufallsalgorithmus erzeugt wurde. Und die Wahrscheinlichkeit, dass da was "sinnvolles" erzeugt wird, ist wie gesagt, verschwindend gering. Und selbst wenn: Der Angreifer kann sich nicht sicher sein, ob der sinnvolle Schlüssel oder ein anderer zufälliger genutzt wurde.  — Felix Reimann 16:39, 16. Dez. 2007 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

OTP mit nicht vollständig zufälligem Schlüssel

@OS: Es ist eine Anforderung des OTP, dass der Schlüssel zufällig sein muss. Ansonsten stimmt die Aussage bezüglich der Sicherheit nicht mehr. Natürlich kann jeder auch einen nicht zufälligen Schlüssel verwenden. Dann ist das jedoch kein OTP mehr. Aber dann kann man auch ein einfacheres Verfahren verwenden. Ich halte es für grob fahrlässig diese Bedingung aufzuweichen. Die Historie zeigt doch, was passiert, wenn Leute meinen, dass man ein Verschlüsselungsverfahren vereinfachen kann. --Stefan Birkner 08:47, 4. Mär. 2008 (CET)

Hallo Stefan Birkner, ich gebe dir völlig recht, es wäre grob fahrlässig mit einem nicht hinreichend zufälligen Schlüssel zu arbeiten. Das habe ich aber auch im Kapitel „Nicht ausreichend zufälliger Schlüssel“ ausführlich erläutert. Auch hast du völlig recht, wenn du sagst, dass die Historie zeigt, was passiert, wenn Leute meinen, dass man ein Verschlüsselungsverfahren vereinfachen kann. Da sind wirklich schon schlimme Fehler passiert. Auf der anderen Seite muss man aber auch nicht nach perfekter Idealität streben. Wie ich schon angemerkt hatte, reicht in der Praxis ein hinreichend gutes Verfahren aus, um ausreichende Sicherheit zu gewährleisten. Um ein Verfahren für die Praxis „unbrechbar“ zu machen, muss es nicht perfekt sicher sein. Das ist aus meiner Sicht eine generell wichtige und richtige Aussage, auf der ich aber gerade im Zusammenhang mit dem OTP nicht herumreiten möchte. Deshalb habe ich das auch im Text nicht ausgewalzt. Andererseits sollte man aber auch nicht den nach meiner Meinung irreführenden Eindruck vermitteln, das OTP würde nur dann funktionieren, wenn der Schlüssel wirklich perfekt zufällig ist. Wie die Praxis bewiesen hat, genügen auch minderwertige Zufalls-Schlüssel, beispielsweise solche, die von Menschen erzeugt wurden, um (wenn sonst keine weiteren Fehler gemacht wurden) die Verschlüsselung nicht brechen zu können. Aber, wie schon gesagt, will ich darauf im Artikel nicht herumreiten. Gruß von --OS 10:43, 4. Mär. 2008 (CET)

Es genügt also aus einem Passwort eine einmalige Zufallsfolge zu erzeugen, die praktisch nicht von einer zufälligen Folge zu unterscheiden ist. Dies ist jedoch mittels einer Hashfunktion h ganz einfach zu programmieren. Mit SHA-1 werden zum Beispiel 20 Byte pro Berechnung erzeugt. Von diesen 20 Byte benutze ich nur ein Byte, etwa das erste oder das letzte. Den n-ten Wert der Zufallsfolge berechne ich als:

    ZUFALL(n) = SHA-1 ( Passwort  +  n )

Die Zufallswerte (ein Byte davon) addiere ich Byte für Byte zum Klartext. Zum Entschlüsseln subtrahiere diese Werte wieder und fertig ist das fast perfekte Verfahren. Wenn das Passwort nur einmal verwendet wird gibt es kein Problem. An das Passwort können die Zahlen 1,2,3 und so weiter oder das Tagesdatum angehängt werden, damit es eindeutig wird. Die Hashfunktion braucht keine besondere Sicherheit aufweisen. Es können also statt SHA-1 auch MD5, SHA-256, SHA-512, und mindestens ein dutzend andere Verfahren verwendet werden. --84.59.34.47 18:56, 20. Nov. 2008 (CET)

An dem Verfahren können natürlich noch tausend winzige Details, das zweite statt dem ersten Byte oder

      ZUFALL(n) = SHA-1 ( 'XX' + Passwort  +  n + n )

oder was einem da sonst noch einfallen mag. Natürlich brauche ich niemand auf die Nase binden wie ich es ganz genau mache. Ein solches Verfahren ist so sicher wie das Passwort schwer zu erraten oder sonst irgendwie zu beschaffen ist. Das Passwort könnte ohne weiteres 128, 256 oder noch mehr Bits haben. Mehr als 128 Bit machen es aber nur schwierig das Passwort zu behalten und sind daher vollkommen sinnlos. --84.59.34.47 18:56, 20. Nov. 2008 (CET)

Überhaupt nicht zu verstehen ist, weshalb in den 90-ern jede Menge angeblich bessere Alternativen zum DES gesucht wurden. Dabei ist es doch mehr als einfach wirklich sichere Verschlüsselung ohne all diesen Quatsch zu realisieren. --84.59.34.47 19:03, 20. Nov. 2008 (CET)

In der Tat gibt es sogar extrem einfache Stromchiffren wie RC4, die mit minimalem Aufwand auf praktisch jedem System realisiert werden können. Wenn das Passwort wirklich zufällig gewählt wird, gilt auch RC4 als sicher. Der RC4 ist noch effizienter als SHA-1, so dass die Berechnung noch schneller erfolgen kann. Dies spielt aber bei heutiger Rechnerleistung eigentlich keine Rolle. Die oben dargestellt Stromchiffre kann auch noch beträchtlich effizienter gestaltet werden, wenn jedes Byte benutzt wird, um gleichzeitig 20 Zeichen bei SHA-1 zu verschlüsseln. Die Zufallsfolge kann ohne Kenntnis des Passworts nicht berechnet werden, selbst wenn der Anfang bekannt wäre und das Passwort kann aus der Zufallsfolge nicht ermittelt werden. Damit können ähnliche Verfahren praktisch nicht gebrochen werden. --88.68.116.129 21:26, 20. Nov. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Überarbeitungen durch Gamgee

Hallo Gamgee, du hast die folgende Textpassage an den Anfang des Kapitels Prinzip gestellt: „Das One-Time-Pad baut auf der über zweihundert Jahre älteren Vigenére-Verschlüsselung auf und gehört wie diese zu den polyalphabetischen Substitutionsverfahren. Bei diesen wird ein einzelner bestimmter Buchstabe (oder Zeichen) des Klartextes anders als bei der älteren monoalphabetisches Verschlüsselung nicht in einen bestimmten Buchstaben des Geheimtextes umgewandelt. Vielmehr gibt es für einen bestimmten Buchstaben des Klartextes mehrere verschiedene mögliche Entsprechungen im Geheimtext und umgekehrt.“ Abgesehen von von dem Svhreibfehler im vorletzten Satz behauptest du falsch, dass „ein einzelner bestimmter Buchstabe (oder Zeichen) des Klartextes anders als bei der älteren monoalphabetisches Verschlüsselung nicht in einen bestimmten Buchstaben des Geheimtextes umgewandelt“ werde. Was du meinst und sagen willst, kann ich mir denken. Du hast es aber falsch formuliert und so ist es missverständlich. Ferner, muss man das OTP nicht zwingend auf der Grundlage der Vigenere-Verschlüsselung sehen. Das wird in der Literatur zwar gelegentlich so dargestellt, ist jedoch keinesfalls zwingend so zu sehen. Gruß von --OS 07:40, 7. Jan. 2008 (CET)

Deswegen muss man aber nicht gleich alles wieder revertieren. Zunächst: Die Vigenére-Verschlüsselung war meines Wissens die erste polyalphabetische Verschlüsselung (auch, wenn andere vor Vigenére die gleiche Idee hatten, aber so ist das ja oft). Das OTP ist auch eine polyalphabetische Verschlüsselung, oder? An der Formulierung kannst Du meinetwegen basteln, aber der alte Zustand bringt die Zusammenhänge, die ich herausarbeiten wollte, gerade nicht zum Ausdruck. Gamgee 17:56, 7. Jan. 2008 (CET)

Auf das Basteln, was du mir freundlicherweise erlaubst, würde ich gerne verzichten. Effizienter wäre es, wenn du sorgfältig editieren und damit das Basteln für uns alle vermeiden würdest. Übrigens, du liegst falsch, denn mehr als ein halbes Jahrhundert vor Vigenére hat Trithemius mit der Tabula recta und dem Vorschlag einer „progressiven Chiffrierung“ bereits eine polyalphabetische Verschlüsselung vorgeschlagen. Und, dass das OTP auch eine polyalphabetische Verschlüsselung darstellt, bedeutet nicht, dass es auf der Vigenére-Verschlüsselung basiert. Gruß von --OS 09:20, 8. Jan. 2008 (CET)

Ist das OTP nicht ein Spezialfall einer Vigènere-Chiffre? Die Länge des Vigènere-Schlüssels ist hier gleich der Klartextlänge und der Schlüssel ist gleichverteilt zufällig. --10:45, 6. Aug. 2010 (CEST) (ohne Benutzername signierter Beitrag von Bananenfalter (Diskussion | Beiträge) )

Hallo Bananenfalter, wie ich vor über zwei Jahren schon einmal versucht hatte zu erklären, kann man es so sehen. Diese Betrachtungsweise ist aber keineswegs zwingend. Man kann das OTP durchaus auch völlig entkoppelt von Vigènere verstehen. Um eine OTP-Verschlüsselung durchzuführen, kann man zwar den Weg über das Vigènere-Quadrat gehen, man braucht es jedoch nicht! Wie im Text beschrieben, funktioniert OTP auch völlig ohne Vigènere-Quadrat ist ist daher auch keinesfalls als ein Spezialfall einer Vigènere-Chiffre zu sehen! Gruß von --OS 10:28, 20. Aug. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

eine Frage bezüglich der notwendigen Zufälligkeit des Schlüssel

Eigendlich gehören Fragen ja nicht in die Diskussionseite von Wiki, aber leider weiss ich nicht wo ich sie sonst stellen sollte. Beim OTP wird ja darauf hingewiesen das der Schlüssel absolut zufälligen sein soll. Was ich nicht so ganz verstehe, wieso das? Ich bin über den Umweg der Büchverschlüsselung zum OTP gekommen und wenn ich mir die Büchverschlüsselung so ansehe meine ich, das diese schon praktisch unknackbar sein dürfte. Setzen wir voraus das der Schlüsseltext wirklich nur dem Absender und Empfänger bekannt ist und keine Fehler beim verschlüsseln gemacht werden, also zb. ein Buchstabe mehrmals mit dem selben Zeichen im Schlüssel verschlüsselt.

Mir als Laie scheint es eigendlich unmöglich aus einem Geheimtext, der ausschließlich nur aus einmalig vorkommenden Zahlen (Buchverschlüsselung) besteht, irgendwelche Rückschlüsse auf den Schlüssel zu gewinnen. Von daher wäre eine Erklärung wieso ein natürlicher Text als Schlüssel weniger sicher ist als eine absolut zufällige Zeichenfolge ist hilfreich. 14.2.2009 schmunzel (nicht signierter Beitrag von 91.0.37.187 (Diskussion | Beiträge) 14:31, 14. Feb. 2009 (CET))

Solange der schlüssel nicht zufällig ist, enthält er muster. durch die xor-verknüpfung sind diese muster auch im geheimtext enthalten. Dieser Umstand dient als anfangspunkt für einen angriff. wenn zum beispiel für den schlüssel ein wort aus dem duden benutzt wird, gelten ja die statistischen eigenschaften der deutschen sprache. so wirst du nach dem "q" nahezu immer ein "u" finden. weiterhin hat jeder buchstabe eine bestimmte häufigkeit: e, n, r, s und t kommen häufiger vor als w oder c. und genau diese vorhersagen setzen sich dann auch im geheimtext fest. werden nun die schlüssel über einen algorithmus berechnen, gibt es auch gewisse regelmäßigkeiten, die aber wesentlich schwerer aufzuspüren sind. dafür gibts ja bekanntlich computer. gruß --Murkel ^(anmurkeln) 17:25, 14. Feb. 2009 (CET)

Diese Grundprinzip wie du es beschreibst ist ja soweit klar, aber....

Wenn ich jetzt z.b einen Text verschlüsseln will und benutze dazu Harry Potter Band 1, Seite 50 und nehme für jedes Klartext E ein anderes E aus besagtem Harry Potter Buch dürfte doch eigendlich kein Muster mehr erkennbar sein. Dito auch bei Kombinationen wie QU, einmal wäre es mit 04.15,09.04 dann mit 10.07,35.12 und das nächste mal mit 16.05,03.18 verschlüsselt. Da beginnt für mich das problem wie man daraus noch ein Muster rausfilter will. Ich gehe dabei davon aus, dass der Schlüssel solang ist wie der zu verschlüsselnde Text und ausserdem jeder Schlüsselbuchstabe nur einmal verwendet wird (nicht signierter Beitrag von 213.196.225.249 (Diskussion | Beiträge) 17:50, 14. Feb. 2009 (CET))

Ich hoffe mal, dass ich deine ausführungen richtig verstanden habe: So wie du das beschreibst, ist es ein korrektes otp. du nutzt zum buchstabenweisen verschlüsseln deines klartextes den buchstaben, den du aus irgendeiner textstelle in diesem buch nimmst. solange du die buchstabenauswahl zufällig vornimmst, sollte das gehen. gruß --Murkel ^(anmurkeln) 23:06, 14. Feb. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 16:02, 4. Jul. 2009 (CEST)

Longpass

dieser thread wurde von einem unangemeldeten user nachtraeglich manipuliert. -- seth 23:49, 17. Feb. 2009 (CET)

Hallo OS, falls ein Interesse besteht, könntest du beim One Time Pad-Artikel auch auf www.longpass.de (Programm Longpass) verlinken (freeware) Es basiert auf OneTimePad. Ist eine Dos-Anwendung. Es lassen sich x-beliebige Dateien verschlüsseln. Mit dem Programm Longpass Passwordcreator lassen sich durch beliebige Input-Files auch ausreichend große und vom Bitmuster abwechslungsreiche Schlüssel erstellen. Mit der Offsetfunktion kann man bei Longpass zum ver/entschlüsseln einen anderen Schlüsselbereich wählen. So lassen sich viele kleine Botschaften verschicken und es wurden zu Beginn nur einmalig zwei sehr große Schlüssel (Gigabyte-Länge) persönlich ausgetauscht.

So könnte nach Generierung (und persönlichen Austausch) zweier 1 GByte großer Passwortdateien durch Longpass Passwortcreator, theoretisch 1 Millionen 1Kbyte große Textnachrichten per email ausgetauscht werden, ohne das ein Schlüsselbereich mehr als einmal verwendet wurde.

new: wusste nicht, dass ich auch ändern darf und hab den link mal gesetzt

(Der vorstehende, nicht signierte Beitrag stammt von 84.187.45.14 (Diskussion • Beiträge) 18:03, 15. Mär. 2008)

Sehr interessant! Danke für deinen Beitrag und Gruß von --OS 10:44, 17. Mär. 2008 (CET)

Gern gesehen. Finde den Artikel sehr gelungen. Auch die Beiträge in den Diskussionen über einen "grünen Bereich" des Zufallspasswortes finde ich recht interessant. Denke schon, dass man die Möglichkeit hat, bestehende Dateien z.B. einen Text sicherer zu gestalten wenn man zumindest den gesamten ASCII-Bereich benutzt. Also im Vergleich:

"FuchsduhastdieGansgestohlen" besteht aus folgenden hex-Werten:

0x46, 0x75, 0x63, 0x68, 0x73, 0x64, 0x75, 0x68, 0x61, 0x73, 0x74, 0x64, 0x69, 0x65, 0x47, 0x61, 0x6E, 0x73, 0x67, 0x65, 0x73, 0x74, 0x6F, 0x68, 0x6C, 0x65, 0x6E,

Ein Angreifer könnte sich auf hex-Werte zwischen 0x40-0x80 konzentrieren, weil Buchstaben als mögliches Passwort wahrscheinlicher sind als folgende Zeichen:

"`¡�ܺ�ÞÉ®�¡ü�c‹L|�E¾õÔä}ƒx)"

Obwohl nur durch einen Generator umgestellt wurde, aber somit die Streuung im ASCII-Bereich größer ist:

0x60, 0xA1, 0x08, 0xDC, 0xBA, 0x07, 0xDE, 0xC9, 0xAE, 0x04, 0xA1, 0xFC, 0x16, 0x63, 0x8B, 0x4C, 0x7C, 0x06, 0x45, 0xBE, 0xF5, 0xD4, 0xE4, 0x7D, 0x83, 0x78, 0x29,

Vom echten Zufall ist man weit entfernt, aber ggf. hat man durch einen beliebigen Satz und deren Umstellung schon den grünen Bereich erreicht.

Wenn nicht, nicht so schlimm. Wichtig ist, dass der BVB im Finale steht:-)

(Der vorstehende, nicht signierte Beitrag stammt von 84.187.47.9 (Diskussion • Beiträge) 23:19, 18. Mär. 2008)

Vorsicht, „sicherer“ heißt nicht unbedingt sicher! Man darf den Gegner nie unterschätzen. Das gilt übrigens nicht nur für die Kryptanalyse sondern auch für den BVB im Pokalfinale ;-) --OS 08:43, 19. Mär. 2008 (CET)

Ja, da muss ich dir recht geben. Beides ist nicht ganz einfach zu lösen. Wahrscheinlich läßt sich sogar OTP eher entschlüsselt als das Staraufgebot der Bayern im Finale zu besiegen. Hätte aber auch nicht gedacht, dass wir z.B. Argentinen bei der WM2006 raushauen könnten.

Geeignete Dateien für OTP zu finden ist nicht leicht. Habe Radiorauschen als wav-Datei über die Soundkarte aufgenommen und das Ergebnis war eher bescheiden. Habe zusätzlich ein Programm erstellt, das ermittelt wie häufig ein Byte in der Datei vorkommt. Dadurch liegt eine Verteilung der ASCII-Bytes vor.

Weil jedes Audio-Format einige Bytes wesentlich häufiger benutzt, sind da starke Abweichungen drin. Ergebniss: Die Unterschiede sind wesentlich stärker als beim Alphabet im normalem Text.

upper limit is = 1394255 (Byte das am häufigsten vorhanden war) lower limit is = 18452 (Byte das am seltesten vorhanden war) average = 41343 (errechneter Durchschnitt)

Ausschitt:

( Byte 0x7c = 18452 Byte 0x7d = 19050 Byte 0x7e = 18798 Byte 0x7f = 1369971 Byte 0x80 = 1394255 Byte 0x81 = 19916)

erst als die wav.datei durch den Generator geschleust wurde, gab es weniger angreifbare Ergebnisse:

upper limit is = 42002 lower limit is = 40922 average = 41343

Ausschnitt:

( Byte 0x7c = 41382 Byte 0x7d = 41504 Byte 0x7e = 41517 Byte 0x7f = 41479 Byte 0x80 = 41147 Byte 0x81 = 41376)

Wichtig wäre, dass Passwörter keine "normalen" Dateiformate sind, weil das Format immer einige Bytes für bestimmte Informationen benutzt und diese treten dann immer wesentlich häufiger auf als andere.

Insgesamt sehe ich OTP in der heutigen Zeit als recht gute Methode an. Erst durch günstige PC´s, DVD-Brenner, DVD-Rohlinge ist das erstellen und benutzen großer Passwortdateien kein finanzieller Kraftakt mehr, sondern recht überschaubar. Wichtig ist, dass man dem User Algorithmen und Analysetools bereitstellen kann, mit denen er diese großen Passwortdateien generieren kann. --84.187.47.54 20:56, 20. Mär. 2008 (CET)RJ

Hallo, habe unsere Diskussion - dein Einverständnis voraussetzend - von meiner Diskussionsseite hierhin verschoben, damit auch andere am Thema OTP interessierte ihr besser folgen können. Eine Quelle für „gute“ Zufallszahlen und alles was mit dem durchaus nicht trivialen Thema „Zufall“ zu tun hat ist Diehard von George Marsaglia. Speziell das dazugehörige Programmpaket Battery of Tests of Randomness zum Test der Qualität der Zufallsverteilung finde ich sehr nützlich. Gruß von --OS 09:34, 25. Mär. 2008 (CET)

Infos zum Longpass-Algorithmus: Ein Klartextbyte wird mit der XOR-Verknüpfung der beiden Passwortdateien XOR-verknüpft und dann wird ein invertiertes (abwechselt) Byte einer Passwortdatei auch das Ergebnis addiert (siehe auch Darstellung: longpass_algorithm.zip unter www.longpass.de) Entscheidend für die Qualität der Verschlüsselung ist die Qualität der Passwortdateien. Wichtig ist, dass das Programm nicht nur Textdateien verschlüsselt, sondern jede Art von Datei(pdf, jpg, mpg u.ä.). Außerdem ist eine Prüfung erfolgt, dass auch große Dateimengen, die über 32-Bit Variablen hinaus gehen (größer 4,29 Gigabyte) verschlüsselt werden können.

Hallo, habe wegen der Übersichtlichkeit beide Longpass-Punkte zusammengelegt und verschlankt. Danke für den Link! Habe mir das Programm bereits runtergeladen und auch schon eine Anpassung beim Programm Passwortcreator vorgenommen. Muss das aber noch mit größeren Passwortdateien testen. Die Informationen sind wirklich sehr nützlich! --84.187.48.231 21:20, 26. Mär. 2008 (CET)

Ergebnis:

Ingesamt liegt der Aufwand, ausreichend zufällige Schüssel zu erzeugen, dank der heutigen PC-Rechenleistung wahrscheinlich im grünen Bereich. Allerdings ist klar, das gängige Dateitypen (z.B. jpeg, mpeg, pdf u.ä) als Schlüsseldatei eher vermieden werden sollten, weil bestimmte Byte-Werte (im Vergleich zu anderen) sehr häufig vorkommen.

Mit Longpass Passwordcreator werden die Probleme der Dateien jedoch beseitigt. Es ist die Eingabe von fünf 16-Bit Werte (5 mal eine Zahl zwischen 0-65535)erforderlich um das Zahlenrad zu füllen, das sich dann dynamisch verändert. Dieses Zahlenrad füllt ein zweites Zahlenrad und die Input-Datei wird ordentlich "durchgewirbelt". Entscheidend für die enstehenden Zufallsbytes ist die Inputdatei und die fünf zufälligen 16-Bit-Werte. Es gibt dadurch also 65535 hoch 5 - Startbedingungen, die jeweils ein anderes Ergebnis liefern.

Auch bei der Inputdatei muss man auf einer hohen Entropie achten. Der einfachste Weg ist, eine gepackte Datei zu verwenden. Ein Packer erhöht die Entropie, weil er "langweilige" Passagen in eine andere "Schreibweise" umwandelt. Dadurch erhöht sich der Differentialanteil und somit auch die Sicherheit recht stark.

Besonders geeignet als Inputdateien sind wav-Dateien mit Aufnahmen eines (extra) schlecht eingestellten Radiosenders. Hier hat man Zufälligkeiten wie Störungen (z.B. durch starke Elektrogeräte die in der Nähe ein/ausgeschaltet werden) oder Unterbrechungen der Musik wegen einer Durchsage usw. Solche Dateien liegen dann aber erst im wav-Format vor und müssen erst durch Longpass Passwordcreator "durchgewirbelt" werden.

Zusätzlich verlangt Longpass zwei Passwortdateien, die XOR-verknüpft in die Verschlüsselung einfließen. Dadurch werden ebenfalls Schwachstellen behoben.

Auch wenn die Rechenleistung der Gegenseite nicht bekannt ist, dürfte man sich daran die Zähne ausbeißen (hoffentlich gelingt dem BVB morgen das gleiche in Berlin gegen dem FCB:-)

--84.187.29.75 00:10, 19. Apr. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Bezeichnungen

Ich habe die Erfahrung gemacht, dass es üblich ist den Klartext als m, den Geheimtext als c und den Schlüssel als k zu bezeichnen. Ich schlage vor diese Terminologie zu übernehmen. (nicht signierter Beitrag von 83.135.140.126 (Diskussion | Beiträge) 23:21, 6. Jan. 2009 (CET))

Zustimmung. Die Bezeichnungen m, k und c sind meiner Meinung nach verbreitet. --Bananenfalter 10:04, 6. Aug. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Nachteile

Absatz 3: "Aufgrund des hohen logistischen Aufwands kann sich das One-Time-Pad für die Verschlüsselung in größeren Kommunikationsnetzen nicht durchsetzen, da sich das System in der Praxis als sinnlos erweist. Anstatt einer sicheren Übertragung eines Schlüssels, der mindestens so lang, wie die zu verschlüsselnde Nachricht ist, könnte man genauso gut die Nachricht selbst sicher übertragen."
Dieser Nachteil gilt natürlich nur, wenn die Nachricht zum Zeitpunkt der Übertragung des Schlüssels bereits bekannt ist. Man könnte jetzt davon ausgehen, dass dies regelmäßig der Fall ist, weshalb dieser Nachteil wohl wegfallen kann. (nicht signierter Beitrag von 84.167.191.137 (Diskussion | Beiträge) 10:37, 13. Feb. 2009 (CET))

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

"einzig" beweisbar sichere

Das one-time-pad ist NICHT das einzige, beweisbar sichere Verfahren. Beispielsweise ist jede Kombination (nacheinanderausführen) von one-time-pad und einem beliebigen Verfahren (unabhängige Schlüssel) ebenfalls "beweisbar sicher". Das mag krümelkackerisch erscheinen, ist aber trotzdem so. Anderes Beispiel könnte sein:

• Schlüssel doppelt so lang wie Nachricht
• für jedes Nachrichten Bit:
  • Klartext 0 + Schlüssel 00 -> Schlüsseltext 0
  • Klartext 0 + Schlüssel 01 -> Schlüsseltext 1
  • Klartext 0 + Schlüssel 10 -> Schlüsseltext 1
  • Klartext 0 + Schlüssel 11 -> Schlüsseltext 0
  • Klartext 1 + Schlüssel 00 -> Schlüsseltext 1
  • Klartext 1 + Schlüssel 01 -> Schlüsseltext 0
  • Klartext 1 + Schlüssel 10 -> Schlüsseltext 0
  • Klartext 1 + Schlüssel 11 -> Schlüsseltext 1

(edit - hab den "Klartext vergessen. --118.137.59.250 11:37, 23. Mär. 2009 (CET))

Das wäre dann genauso sicher wie one-time-pad (nicht unbedingt effizienter). Sinnvolle Anwendungen könnten die Einflechtung von fehlerkorrigierenden Codes sein (das ist aber nicht mein Punkt - "einzig" ist auch ohne "sinnvolle" Alternative falsch!).

Was definitiv gilt ist: Das one-time-pad ist bezüglich Schlüssellänge optimal, oder: "Es kann kein beweisbar uneingeschränkt sicheres Verfahren geben, bei dem der Schlüssel kürzer als der Klartext ist." --118.137.59.250 11:34, 23. Mär. 2009 (CET)

Du hast recht. Letzteres sollte noch klar hervorgehoben werden, weil es einfacher verständlich ist als "optimale Schlüssellänge" -- PaterMcFly Diskussion ^Beiträge 11:49, 23. Mär. 2009 (CET)

Wenn schon korinthenkacken, dann aber richtig: Dieser Beweis gilt ja wohl nur, wenn der Klartext keine Redundanzen enthält. Sonst könnte ich den Klartext ja komprimieren, und dann brauche ich vielleicht nur noch 1/10 so viel one-time-pad. Wenn der Klartext aber keine Redundanz hat, ist "beweisbar sicher" schwer zu definieren. Wie soll der Angreifer rauskriegen, ob er den richtigen Schlüssel rausgefunden hat, wenn er dem Klartext nicht ansehen kann, ob es der richtige ist? --Maxus96 15:31, 4. Jul. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Belegbaustein (erl.)

Hallo Maxus96, statt einfach den Belegbaustein in den Artikel einzufügen, so wie du es eben gemacht hast, wäre es auch denkbar gewesen, deinen Belegwunsch, nämlich, "dass der „Heiße Draht“ (auch als das „Rote Telefon“ bekannt), also die hochsichere direkte Fernschreibverbindung zwischen dem amerikanischen Präsidenten und dem sowjetischen Generalsekretär, durch ein Einmalschlüssel-Verfahren geschützt wurde", auch hier auf der Diskussionsseite zu äußern. Habe mir erlaubt, sowohl den nachgefragten Passus als auch den Baustein zu entfernen und werde dir den Beleg nachreichen (und dann auch den Passus wieder einfügen). Den Beleg hättest du übrigens auch gleich selbst in einer der im Literaturverzeichnis angegebenen Quellen, beispielsweise Bauer oder Kippenhahn, suchen und finden können und am besten dann auch gleich selbst im Artikel ergänzen können. Vermisst du noch weitere Belege und hast du noch weitere Belegwünsche oder ist es dann gut? Gruß von --OS 09:41, 23. Apr. 2010 (CEST)

Auch Kahn berichtet in The Codebreakers auf Seite 716 (engl. Ausgabe von 1996) von einer per OTP-geschützten Verbindung zwischen Weißem Haus und Kreml. Pinoccio 11:08, 23. Apr. 2010 (CEST)

Hallo Pinoccio, danke für den Hinweis! Gruß von --OS 13:26, 23. Apr. 2010 (CEST)

Hui, hui, Spinnweben gefrühstückt? Bauer und Kippenhahn stehen leider nicht bei mir auf dem Nachttisch, sorry. Ich finde es nur immer verdächtig, wenn irgendwo irgendwas über "rote Telefon" behauptet wird, was so totaaaal einleuchtend klingt. Unabhängig davon, ob es nu stimmt, ist die Wahrscheinlichkeit hoch, daß der Eintrag weniger auf Fakten als auf Kolportage beruht. Okay?

Dieser Belegwunsch-Baustein war von mir nicht als Beleidigung gedacht.

Gruß, -- Maxus96 17:33, 23. Apr. 2010 (CEST)

Du hast mich nicht beleidigt. Gruß von --OS 06:54, 26. Apr. 2010 (CEST)

Simon Singh ist ja nicht gerade ein Primärbeleg, aber das Buch wollte ich schon lange mal lesen. Danke für die Erinnerung. ;-) Gruß, -- Maxus96 19:59, 26. Apr. 2010 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Maxus96 19:59, 26. Apr. 2010 (CEST)

Literatur

Der Link zu "Robert Louis Benson: The VENONA Story" geht nicht. Ich habe da mal einen neuen reingestellt. Wäre gut, wenn jemand, der das ursprüngliche Dokument hat bestätigen könnte, dass es sich um das gleiche Dokument handelt. --Sg050 23:11, 13. Jan. 2010 (CET)

Ja, danke, der neue Link passt perfekt! Gruß von --OS 10:24, 22. Aug. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Handelsübliche Rechner

"Handelsübliche Rechner sind nicht in der Lage, wirklich zufällige Schlüssel zu erzeugen."

Sind sie wohl. Siehe /dev/random --93.82.36.57 22:53, 30. Jan. 2011 (CET)

Das hängt davon ab, was man unter „handelsüblich“ versteht. Klar gibt es Spezial-Hardware zur Erzeugung möglichst zufälliger Ereignisse, aber die üblichen Rechner aus dem Elektronik-Handel (um die Ecke) verfügen nicht über diese Fähigkeit. Insofern halte ich die Formulierung im Artikel für statthaft. Danke für deinen Hinweis und Gruß von --OS 10:28, 22. Aug. 2011 (CEST)

Es gibt massenhaft Möglichkeiten gleichverteilt zufällige Zahlen an einem handelsüblichen Rechner zu generieren. Beispiele:

• Thermisches Rauschen von Widerständen
• Mausbewegungen
• Audioeingänge

Zeig mir den "Handelsüblichen Rechner" in dem sich nicht ein einziger Widerstand befindet und der keine Unterstützung für Eingabegeräte hat. --Dr.üsenfieber (Diskussion) 12:05, 18. Feb. 2014 (CET)

Der besagte Satz findet sich aktuell nicht (mehr) im Artikel. Ist damit wohl erledigt.--Plankton314 (Diskussion) 13:07, 18. Feb. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 13:07, 18. Feb. 2014 (CET)

Kompromittierter Schlüssel?

Laut Artikel sind die Schlüssel aus den Beispielen nicht mehr Sicher, weil Sie bereits veröffentlich wurden. Weiterhin ist sinnvoller Text ebenfalls kein guter Schlüssel. Genau das widerspricht sich mit der Aussage des Artikels, dass ein echter Zufallsschlüssel nicht geknackt werden kann. Ein echter Zufallsschlüssel muss natürlich auch zufällig ein Bibelzitat oder die "kompromitierten" Schlüssel der Wikipedia enthalten - auch wenn diese Buchstabenfolge unwahrscheinlich ist, muss sie auftreten können, sonst es ist ein aussortierter Zufallsschlüssel. Sinnvoller Text hängt ja nur vom Wissen des Betrachters ab, eine für uns sinnlose Buchstabenfolge kann in einer anderen Sprache eine Bedeutung haben. Genau da beißt sich die Katze in den Schwanz, die Qualität wäre dann nämlich abhängig von der zufälligen Qualität meines Abschnitts des Zufallsschlüssel. Irgendwas stimmt also nicht. -- Jackie251 16:59, 28. Sep. 2011 (CEST)

es ist sicherlich keine gute idee, den schluessel aus der WP zu verwenden, denn den kennt ja jeder. falls du allerdings einen zufaelligen schluessel aus 21 buchstaben wuerfelst und dieser dabei herauskommt, dann solltest du ihn auch verwenden. eine grundannahme ist naemlich, dass der angreifer weiss, auf welche weise du den schluessel generiert hast. wenn du also einfach den schluessel aus der WP nimmst, dann weiss der angreifer, dass du diesen schluessel verwendest. wenn du dir einen (gleichverteilt) zufaelligen schluessel ziehst, dann weiss der angreifer, dass du diesen schluessel mit w'keit 1/26^21 verwendest - genau wie alle anderen moeglichen. was sich also aendert, ist die grundgesamtheit, aus der der schluessel gezogen wird. genauso solltest du keinen sinnvollen text als schluessel verwenden. falls du aber einen zufaelligen schluessel ziehst, und er zufaellig sinnvoll ist, dann verwende ihn. es geht nicht um den schluessel an sich, sondern um die menge, aus der er stammt und wie er gewaehlt wurde. ich werde mal schauen, wie man das im artikel praezisieren kann. --Mario d 22:55, 28. Sep. 2011 (CEST)

Ihr dürft beide bitte nicht übersehen, dass die Zufälligkeit des Schlüssels allein nicht ausreicht. Im Artikel ist nachzulesen, dass er geheim bleiben muss, unvorhersagbar zufällig sein muss und nur einmal verwendet werden darf. Erst wenn alle drei Punkte erfüllt sind, ist er sicher. Da beißt sich nichts in den Schwanz! Gruß von --OS 12:51, 6. Okt. 2011 (CEST)

das ist richtig, aber was willst du damit sagen? wenn ich mir zufaellig den schluessel aus dem artikel ziehe, dann muss ich ihn auch verwenden. und aus welchem grund hast du meine aenderungen revertiert? --Mario d 12:59, 6. Okt. 2011 (CEST)

Hallo Mario, wie ich dir gerade schon auf meiner privaten Diskussionsseite geschrieben hatte, war dein Beitrag grammatikalisch inkorrekt. Wie ich finde, sollte man bei Überarbeitungen des Artikels so sorgfältig vorgehen, dass zumindest die Regeln der deutschen Sprache erfüllt sind. Darüber hinaus ist mein Eindruck, dass deine Änderung auf der hier mit Jackie durchgeführten Diskussion basiert. Diese halte ich für im Kern an der Thematik vorbeigehend, wie ich oben kurz versucht habe, zu begründen. Ferne halte ich auch deine Texteinfügung „Da davon ausgegangen werden muss, dass ein Angreifer weiß, auf welche Weise Schlüssel generiert werden, ist dieser Schlüssel mit der Veröffentlichung in der Wikipedia ist natürlich kompromittiert...“ für sachlich falsch oder zumindest für irreführend. Denn entscheidend ist hier nicht, ob der Angreifer weiß, auf welche Weise der Schlüssel generiert worden ist, sondern wichtig ist, dass er ihn kennt. Damit ist der Schlüssel kompromittiert und nicht länger geheim und insofern unbrauchbar. Sei mir deshalb bitte nicht böse, wenn ich deine Frage hier klar beantworte. Ich schätze dich als Wikipedia-Kollegen und hoffe weiterhin auf gute Zusammenarbeit! Aber in diesem konkreten Fall fand der Beitrag weder in grammatikalischer noch in sachlicher Hinsicht meine Zustimmung. Daher hatte ich mir erlaubt, ihn zu revertieren. Gruß von --OS 13:16, 6. Okt. 2011 (CEST)

fangen wir mit den fachlichen fragen an, bevor wir grammatik diskutieren (bei der ich uebrigens keine fehler feststellen kann). stimmst du mir zu, dass wir aufgrund von Kerckhoffs’ Prinzip annehmen muessen, dass der angreifer weiss, wie die schluessel generiert werden? das ist eine ganz entscheidende frage, da du mir sicherlich keine gute definition von "kennt" liefern kannst. --Mario d 13:31, 6. Okt. 2011 (CEST)

Hallo Mario, über deinen grammatikalischen Fehler brauchen wir nicht zu diskutieren. Wenn du dir den von dir eingefügten Satz, den ich oben zitiert hatte, einfach nur einmal sorgfältig durchliest, wirst du sicher erkennen, dass im Satzteil mit „Wikipedia“ das Wort „ist“ zwei Mal auftritt. (Hab' mir übrigens auch erlaubt, euer Einverständnis voraussetzend, den Titel dieses Diskussionsabschnittes orthographisch zu korrigieren.) Zum Thema: Zu Beginn dieser Diskussion hatte Jackie die Aussage aufgestellt: „Ein echter Zufallsschlüssel muss natürlich auch zufällig ein Bibelzitat oder die "kompromitierten" Schlüssel der Wikipedia enthalten“. Eine etwas andere aber ebenso (in der Praxis) falsche Aussage hatte weiter oben (Kapitel: Brute Force) ein anderer Wikipedianer aufgestellt, der behauptete: „Bei der Mitteilung mit den 21 Buchstaben wäre auch der Rechenaufwand überschaubar...“ Beide Kollegen übersehen, dass Krypthographie und Kryptanalyse zwar sicher auch philosophische und theoretische (bis hin zu extremtheoretischen) Aspekte aufweisen, aber die Frage nach der Sicherheit zumeist in der Praxis entschieden wird. Wie weiter oben nachzulesen, gibt es für eine zufällige Buchstabenfolge aus (nur) 21 Buchstaben (wobei wir uns nur auf die 26 Großbuchstaben beschränken) bereits 518.131.871.275.444.637.960.845.131.776 mögliche unterschiedliche Texte. Das ist eine solch gigantisch große Menge, dass wir sie uns alle nicht im entferntesten vorstellen können. Sie ist so groß, dass es beispielsweise deutlich wahrscheinlicher ist, dass jemand drei Mal hintereinander im Lotto einen Sechser hat und am darauffolgenden Sonntag exakt um 12 Uhr mittags in der selben Sekunde vom Blitz getroffen und gleichzeitig von einem Meteoriten erschlagen wird als dass in dieser Menge von Zufallstexten „zufällig“ einmal ein halbwegs sinnvoller Text, geschweige denn ein Bibelzitat oder gar der (im Artikel als Beispiel angegebene und damit) kompromittierte Schlüssel gefunden wird. Natürlich steckt der darin, aber in der Praxis wirst du ihn nicht finden und ich auch nicht, weil ich nicht lange genug leben werde, und mein Computer auch nicht, weil es dafür nicht lange genug Strom geben wird und auch sonst niemand auf der Erde, weil die Erde nicht lange genug existieren wird... Bitte erspart uns hier die unfruchtbaren extremtheoretischen Diskussionen, die immer wieder aufflammen und zumeist von Menschen entfacht werden, die sich tatsächlich niemals mit echter Kryptanalyse in der Praxis befasst haben. Nur von theoretischen Überlegungen ohne „praktischen Bodenkontakt“ ausgehend fällt es schwer, diese nicht einfach einleuchtenden Tatsachen einzusehen. Aber tatsächlich braucht niemand zu wissen, ob der Angreifer weiss, wie der Schlüssel generiert wurde. Und hier muss auch nicht gezeigt werden, ob jemand eine gute Definition von „kennt“ liefern kann oder nicht. Wichtig ist schlicht die Erkenntnis, wenn der Verschlüssler die oben angegebene gigantisch große Menge an Zufallstexten zur Auswahl für seinen Schlüssel hat, dass es dann (um es höflich zu formulieren) nicht besonders intelligent wäre, eine bereits veröffentlichte Textpassage (noch dazu aus einem Wikipedia-Artikel, auf den jederman leicht Zugriff hat) und, Mario, die der Angreifer deshalb „kennen könnte“, als Schlüssel zu wählen. Die Menge aller weltweit publizierten Texte ist nämlich verschwindend gering, unvorstellbar verschwindend gering, um nicht zu sagen, praktisch gleich Null, im Vergleich zur Menge aller Zufallstexte. Deshalb ist es extrem viel sicherer, einen (um es noch ein letztes Mal zu wiederholen) geheimen und unvorhersagbar zufälligen und nur ein einziges Mal zu verwendenden Zufallstext zu benutzen und keinen bekannten Text. Darauf habe ich auch im Artikel ausdrücklich hingewiesen: „Textpassagen als Schlüssel, selbst wenn sie einmalig sind, [...] dürfen keinesfalls verwendet werden.“ Zum Abschluss vielleicht noch zwei kleine Gedankenexperimente für euch beide. Ich behaupte, mit ganz viel Glück kann ich jedes OTP auf Anhieb knacken! Beweis: Ich brauche mir ja nur irgendeinen beliebigen legalen Schlüssel auszudenken. Und wenn ich dabei (unendlich) viel Glück habe, ist es „zufällig“ der richtige, mit dem ich dann den Text ganz leicht entschlüsseln kann. Es kommt aber noch besser: Ich brauche weder den Schlüssel noch den Geheimtext überhaupt zu kennen und kann den (mir völlig unbekannten) Text dennoch knacken! Beweis: Ich erstelle mir ein Buch mit allen Zufallstexten bis zu einer beliebigen Länge L. Dann schlage ich das Buch an einer beliebigen Stelle auf. Mit erneut (unendlich) viel Glück ist das „zufällig“ der korrekte Klartext. Weiterhin viel Spaß mit der Kryptologie! Gruß von --OS 06:32, 7. Okt. 2011 (CEST)

es ist sehr bedauerlich, dass du meiner frage ausweichst und stattdessen mit dieser textwueste antwortest. bist du wirklich nicht bereit, dich ueberzeugen zu lassen? die aussage „Ein echter Zufallsschlüssel muss natürlich auch zufällig ein Bibelzitat oder die "kompromitierten" Schlüssel der Wikipedia enthalten“ ist vollkommen richtig und der vergleich mit jener anderen aussage voellig unangebracht. dadurch, dass du sinnvolle texte aus der schluesselmenge ausschliesst, verkleinerst du sie und gibst dem angreifer hinweise auf den klartext, den er sonst nicht haette. das macht das verfahren unsicherer, als es sein koennte. deshalb ist dein hinweis „Textpassagen als Schlüssel, selbst wenn sie einmalig sind, [...] dürfen keinesfalls verwendet werden.“ in dieser form eindeutig falsch.

ein beispiel: die klartextmenge, chiffratmenge und schluesselmenge sei jeweils die menge der kleinbuchstabenfolgen der laenge zwei. fuer eine nachricht, die ich verschluesseln will, waehle ich einen zufaelligen der 676 schluessel aus und erhalte damit also eines der 676 moeglichen chiffrate. nehmen wir weiterhin an, dass die nachricht entweder "ja" oder "ne" ist, und der angreifer das weiss (aufgrund des kontextes). wenn das chiffrat nun "og" ist, so gibt es fuer ihn zwei moeglichkeiten: entweder die nachricht war "ja", dann war der schluessel "ef", oder die nachricht war "ne" und der schluessel "ab". da beide schluessel gleich wahrscheinlich sind, weiss er jetzt, wo er das chiffrat gesehen hat, genauso viel wie vorher. wuerden wir "sinnvolle" schluessel nicht benutzen, waere der fall jetzt klar, denn "ab" ist ein deutsches wort, kaeme also als schluessel nicht in frage. die nachricht muss also "ja" sein. durch unsere wahl des schluessels kann der angreifer die verschluesselung brechen.

ich finde es sehr schade, dass du theoretischen ueberlegungen fuer belanglos haeltst. dennoch gibt es sie, und da wir hier eine enzyklopaedie schreiben, sollte ihnen auch der gebuehrende platz eingeraeumt werden. der artikel befasst sich eben mit dem OTP, nicht nur mit seiner praktischen kryptoanalyse. es gibt ein paar fakten ueber das OTP, die auch dann fakten bleiben, wenn du sie fuer "extremtheoretisch" haeltst. --Mario d 11:46, 7. Okt. 2011 (CEST)

Hallo Mario, vielleicht darf ich dich daran erinnern, dass der Wunsch zu einer Löschbegründung deiner grammatikalisch und sachlich falschen Texteinfügung nicht von mir stammt, sondern von dir so auf meiner Benutzerdiskussionseite geäußert wurde? Gerne hätte ich auf diese Erläuterungen verzichtet, aber, wenn du sie schon von mir wünscht und ich sie dir wunschgemäß gebe, dann, finde ich, ist es ein Gebot der Höflichkeit, dass du sie mit dem nötigen Respekt behandelst und auch aufmerksam liest. Bewusst hatte ich versucht, dir meinen Standpunkt möglichst umfassend und verständlich darzulegen und uns beiden so langwierige Textwechsel zu ersparen, die ich nach deiner Ankündigung befürchten musste. Aus didaktischen Gründen habe ich meine Erläuterungen auch anhand von „extremtheoretischen“ Beispielen von „geglückten“ Entzifferungen möglichst anschaulich und klar illustriert. Leider hat alles nicht gefruchtet und du hast den Kern deines Irrtums, wie man deiner Antwort entnehmen kann, noch immer nicht erkannt. Ob der Grund dafür in meinen mangelhaften didaktischen Fähigkeiten liegt oder eher darin zu suchen ist, dass du meine von dir so bezeichnete „Textwüste“ nur überflogen und nicht aufmerksam genug gelesen hast, kannst du sicher besser beurteilen als ich. Ich bin mit den Fakten durchaus vertraut und glaube, deine Argumentationskette und auch das Ziel deiner Argumentation verstanden zu haben. Du bist übrigens nicht der Erste, der mir diese Argumente vorträgt und du wirst – so sicher wie das OTP unbrechbar ist – auch nicht der Letzte sein, dem dieser fundamentale Gedankenfehler unterläuft. Um den einzusehen, würde es vielleicht helfen, meine „Textwüste“ aufmerksam zu lesen, so wie es dir vielleicht auch geholfen hätte, deinen eigenen Textbeitrag im Artikel einmal genau durchzulesen, in dem du ja auch keinen grammatikalischen Fehler feststellen konntest, obwohl auch dort der Fehler klar zu erkennen war. Immerhin konnten wir uns die von dir angekündigte Diskussion über Grammatik glücklicherweise schenken. Vielleicht gelingt es mir ja mit meinem zweiten Erklärungsversuch, dich zu überzeugen? Beginnen wir dazu ruhig mit dem von dir konstruierten Beispiel eines Textes der Länge Zwei. Du gibst richtig an, dass es für solch einen kurzen Text (unter den von dir formulierten Randbedingungen) 676 mögliche Schlüssel und ebenso viele mögliche Geheimtexte gibt. Du erläuterst mir die offensichtlich schwerwiegenden Nachteile, die man „unserem“ so sicheren OTP-Verschlüsselungsverfahren zufügt, wenn man fahrlässigerweise (so ignorant wie ich ;-o), all die vielen Zufallsschlüssel, die zufällig einen sinnvollen Text ergeben, von der Verwendung ausschließt. Du nennst das deutsche Wort AB als ein Beispiel. Der Fall, den du betrachtest mit einer Länge von nur Zwei, ist jedoch (in meiner frechen Nomenklatur) ein „extremtheoretischer“ Fall, fast schon ein Grenzfall, der dich, wie du vielleicht gleich einsehen wirst, in die Irre und zu falschen Schlussfolgerungen führt. Um die Gefahr, die von der Betrachtung solcher Extremfälle ausgeht, schnell einzusehen, könntest du deinen Beispielfall mit einer Textlänge von Zwei einfach um noch ein Zeichen also dann auf die Länge von Eins verkürzen. Nun könntest du beispielsweise mir illustrieren und (völlig korrekt) beweisen, dass selbst ein Caesar plötzlich systemtheoretisch sicher, also unknackbar ist, eine Erkenntnis, die bei praktisch sinnvollen Textlängen (von mehr als einem Buchstaben) hingegen völlig falsch ist. Falls das Einsehen jedoch länger dauert, kann dir vielleicht die folgende theoretische Überlegung helfen, wobei du allerdings konkret etwas mitarbeiten müsstest? Bitte berechne dazu zunächst für eine Textlänge von 21 (wie als Beispiel im Artikel, die ja tatsächlich noch immer kurz für eine normale Nachricht ist,) und danach für einen praktisch relevanten Text mit einer Länge von sagen wir mal 250 Zeichen, die Anzahl der möglichen Zufallsschlüssel und stelle anschließend dieser Zahl die (als Teilmenge darin enthaltene und) von dir bitte näherungsweise zu schätzende Anzahl von „sinnvollen“ Texten gegenüber. Diese Teilmenge ist es doch, die dir und Jackie besonders am Herzen liegt, und die ihr beide gegen meine Ignorierungsversuche verteidigt. Du musst dich bei deiner Schätzung selbstverständlich nicht auf deutschsprachige Texte beschränken, sondern darfst gerne alle Sprachen dieser Welt, auch alle Dialekte, und, wenn du möchtest, selbst Klingonisch und andere fiktive oder ausgestorbene Sprachen nach Belieben dazunehmen. Abschließend musst du nur noch beide Zahlen durcheinander dividieren. Dann erhältst du die Wahrscheinlichkeit dafür, wie häufig du in einem Zufallstext einen „sinnvollen“ Text finden kannst. Falls du angesichts deines Rechenergebnisses noch immer behauptest, die Auftretenshäufigkeit eines „sinnvollen“ Textes innerhalb eines Zufallstextes habe eine praktische Relevanz, und sei nicht (theoretisch und praktisch) so dicht bei Null, dass es keinen Sinn macht, über diese Marginalie weiter zu diskutieren, dann muss ich noch einen allerletzten Versuch unternehmen, dich zu überzeugen, und dich bitten, das folgende Gedankenexperiment durchzuführen: Überlege dir doch bitte mal, ob es ein guter Rat wäre, bei einem Passwortgenerator, der beispielsweise zum Schutz deines Computers jeden Monat ein neues Passwort der Länge Acht aus den 26 Großbuchstaben generiert und der beim letzten Mal ein Passwort wie MFTAKVHL vorgeschlagen hatte und nun „zufällig“ die Buchstabenfolge PASSWORT generiert, diesen Vorschlag anzunehmen und diese Buchstabenkombination für den nächsten Monat zu verwenden, weil es laut deiner Argumentation nur so richtig wäre, da man ansonsten „dadurch, dass du sinnvolle texte aus der schluesselmenge ausschliesst, [sie] verkleinerst“ und dadurch „das verfahren unsicherer“ machst? Offensichtlich ist doch genau das Gegenteil richtig und es wäre für jeden Benutzer fatal, deinen Rat zu befolgen und explizit auch Textpassagen wie dieses „zufällig“ generierte Passwort als Schlüssel zu benutzen, so wie du es ausdrücklich empfiehlst. Das wäre ein schlimmer kryptographischer Fehler! Es steht dir natürlich frei, deinem eigenen Rat zu folgen, auch wenn er schlecht ist. Übrigens, es ist wenig hilfreich, mir Aussagen zuzuschreiben, die ich nicht geäußert habe. Beispielsweise zum Bibeltext hatte ich klar und deutlich geschrieben: „Natürlich steckt der darin, aber in der Praxis wirst du ihn nicht finden...“ Und, dass ich theoretische Überlegungen für belanglos halte, wie du mir unterstellst, ist völlig falsch und das habe ich nie gesagt. Deine Betrachtungen von auf die Länge Zwei verkürzten (um nicht zu sagen: „extremtheoretisch“ verstümmelten) Texten führen dich jedoch zu irrigen Schlussfolgerungen. Genau davor versuche ich dich zu warnen und die Leser unserer Wikipedia zu bewahren. Gruß von --OS 06:24, 10. Okt. 2011 (CEST)

du argumentierst in eine voellig falsche richtung. hier nochmal mein argument in kuerze:

1. das OTP mit zufaelliger schluesselwahl ist informationstheoretisch sicher.
2. das OTP mit deiner schluesselwahl ist praktisch sicher, aber nicht informationstheoretisch sicher.

daraus folgt:

1. deine schluesselwahl macht das OTP unsicherer.

in der praxis wird der fall, dass ein zufaellig gewaehlter schluessel ein sinnvoller text ist, fast nie auftreten (die wahrscheinlichkeit ist vernachlaessigbar in der schluessellaenge). ich hatte dich allerdings bereits darauf hingewiesen, dass der standpunkt der praktikers hier nicht der einzig relevante ist.

zu deinem letzten beispiel: kannst du begruenden, warum es ein "schlimmer kryptographischer Fehler" waere, den schluessel "PASSWORT" zu benutzen? falls deine antwort ist "weil der angreifer ihn raten kann", bedenke bitte, dass er mit wahrscheinlichkeit 1/26^8 gezogen wurde, so wie alle anderen zeichenketten der laenge 8. der angreifer, der "PASSWORT" raet, ist nicht im allgemeinen nicht erfolgreicher, als der angreifer, der "AJHENUML" raet. mein argument aus dem letzten beitrag geht genauso fuer jede beliebige schluessellaenge durch und zeigt, dass deine schluesselwahl die inf.th. sicherheit des OTP zerstoert. --Mario d 17:04, 10. Okt. 2011 (CEST) PS: bitte teile mir auf jeden fall fuer jeden der oben genannten saetze 1-3 mit, ob du ihn fuer wahr oder falsch haeltst. --Mario d 17:29, 10. Okt. 2011 (CEST) PPS: es kommt ja praktisch nie vor, dass ein zufaelliger schluessel ein sinnvolles wort ist (das wolltest du mir eben erklaeren). warum bestehst du darauf, schluessel nicht zu benutzen, die praktisch nie vorkommen? --Mario d 21:22, 10. Okt. 2011 (CEST)

Schade, dass du erneut nicht auf meine freundlich formulierten und ausführlich dargelegten Argumente eingehst, sondern ähnlich, wie du sie davor als „textwueste“ abgeschmettert hattest, nun alles mit deiner knappen Bemerkung „du argumentierst in eine voellig falsche richtung“ vom Tisch wischst. Dabei bist du es, der noch immer in eine völlig falsche Richtung denkt und argumentiert, denn nur dadurch, dass man vernachlässigbar wenige aber schlechte Schlüssel (klugerweise) nicht benutzt, wird ein unknackbares Verfahren nicht plötzlich brechbar. Aber, wenn jemand dumme Schlüssel benutzt, dann kann ihm auch das sicherste Verfahren der Welt keine kryptographische Sicherheit bieten. Wem nicht zu raten ist, dem ist auch nicht zu helfen! Wie ich schon sagte: Benutz' du ruhig PASSWORT oder noch bequemer ZZZZZZZZ als Schlüssel, wenn du dies auch weiterhin für „informationstheoretisch sicher“ hältst, aber bitte arbeite deine Empfehlung nicht in den Artikel ein! Gruß von --OS 06:28, 12. Okt. 2011 (CEST)

du argumentierst oben, dass das OTP auch mit deiner modifikation praktisch sicher sei, da sind wir aber einer meinung. deshalb argumentierst du in die voellig falsche richtung, wenn du mich von etwas zu ueberzeugen versuchst, was ich gar nicht bestreite. leider hast du meine drei fragen nicht beantwortet, obwohl ich ausdruecklich darum gebeten hatte. ich werde dich wohl nicht ueberzeugen koennen, das muss ich aber gluecklicherweise auch gar nicht. ich werde eine von reputablen quellen belegte darstellung des OTP in den artikel einbauen und dort wird sicherlich nichts von "schlechten schluesseln" stehen, die gibt es beim OTP naemlich nicht. ich wuerde dich bitten, dies dann nicht auf deine privatmeinung zu aendern, falls du fuer deine behauptungen keine belege liefern kannst. diese belege sollten die wahl des schluessels beim OTP betreffen und nicht die auswahl von passwoertern, ein thema, das hiermit nichts zu tun hat. --Mario d 10:35, 12. Okt. 2011 (CEST)

PS: eine beschreibung des OTP gibt es bswp. in Buchmann: Einführung in die Kryptographie. --Mario d 10:57, 12. Okt. 2011 (CEST)

ich habe meine aenderungen eingearbeitet. die verwirrenden passagen habe ich einfach herausgenommen, die schluesselwahl wird ja bereits in der beschreibung des verfahrens erklaert. diesen abschnitt habe ich umgeschrieben und gestrafft. falls die aenderungen nicht deine zustimmung finden, revetiere sie bitte nicht einfach, sondern erklaere hier auf der disku wo du probleme siehst. --Mario d 13:56, 14. Okt. 2011 (CEST)

Offensichtlich hast du übersehen, dass ich dir deine Fragen beantwortet hatte. Gruß von --OS 07:30, 24. Okt. 2011 (CEST)

wie bereits gesagt, falls du eine reputable quelle fuer deine theorie findest, dass es beim OTP schwache schluessel gaebe, koennen wir gerne weiterdiskutieren. ansonsten sehe ich dafuer keine grundlage. --Mario d 12:42, 24. Okt. 2011 (CEST)

Es handelt sich nicht um „meine Theorie“. Eine Quelle hatte ich bereits genannt. Gruß von --OS 11:23, 28. Okt. 2011 (CEST)

tut mir leid, ich finde in deinem beitrag die quelle nicht. kannst du sie bitte nochmal nennen? --Mario d 11:43, 28. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Vernam

in bezug auf diesen revert: mir waere neu, dass es eine mindestartikellaenge gibt, unterhalb der sich verlinken nicht lohnt. ich sehe auch nicht, warum ein link jemanden verwirren sollte, denn er macht klar, dass es sich nicht mehr um das OTP handelt, sondern um ein anderes verfahren (das leicht gebrochen werden kann, was im artikel noch zu ergaenzen waere), wenn der schluessel anders gewaehlt wird. --Mario d 21:07, 10. Okt. 2011 (CEST)

Ich hatte Dürftigkeit kritisiert nicht Länge. --OS 06:30, 12. Okt. 2011 (CEST)

das argument leuchtet mir nicht ein. es werden in der WP sogar noch gar nicht existierende artikel verlinkt, wenn das lemma passend ist (diese sind dann rot). ich weiss von keinem verbot, "duerftige" artikel zu verlinken. --Mario d 10:37, 12. Okt. 2011 (CEST)

Wer spricht denn von einem Verbot? Es geht darum, unsere Wikipedia möglichst gut zu gestalten! Wenn auf einen nicht existierenden Artikel verlinkt wird, ist der Link rot, damit man weiß, dass sich der Klick nicht lohnt. Wenn du unsere Wikipedia verbessern helfen möchtest, dann konzentriere dich lieber darauf, Vernam-Chiffre zu verbessern, statt diesen hier zu verschlechtern. Gruß von --OS 07:26, 24. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Fehlerhafte Verwendung von Textpassagen als Schlüssel

Hallo Mario, obwohl ich dir den Sachverhalt ausführlich erläutert hatte, und dich gebeten habe, es nicht zu tun, hast du einen sehr wichtigen Passus im Artikel ersatzlos gelöscht, der den folgenden Warnhinweis enthielt: „Textpassagen als Schlüssel, selbst wenn sie einmalig sind, erfüllen diese Forderung nicht und dürfen keinesfalls verwendet werden. Aufgrund von statistischen Abhängigkeiten des Schlüssels kann es sonst einem Angreifer gelingen, in die Verschlüsselung einzubrechen und den Geheimtext zu entziffern.“ Bitte belege die Legitimität und Sinnhaftigkeit deiner Löschung anhand einer seriösen Literaturstelle, aus der hervorgeht, dass die Verwendung von Klartextpassagen als Schlüssel ausdrücklich empfohlen oder zumindest als unbedenklich angesehen wird, und nicht als im Widerspruch zur Forderung nach „Unvorhersagbarer Zufälligkeit“ des Schlüssels zur Verhinderung einer ansonsten gefährlichen Einbruchsmöglichkeit angesehen wird! Solange du diesen Beleg in Form eines Zitates einer Veröffentlichung eines renommierten Autors nicht vorlegst, bitte ich dich im Interesse der Leser unserer Wikipedia, den Artikeltext nicht zu verstümmeln und den Hinweis nicht zu löschen! Er ist korrekt, wie beispielsweise bei Friedrich L. Bauer: Entzifferte Geheimnisse, Methoden und Maximen der Kryptographie. Springer, Berlin 2000 (3. Aufl.), ISBN 3-540-67931-6, S. 157 nachzulesen „Die [...] Zeichenfolgen sollten natürlich keinerlei Gesetzmäßigkeit genügen, sondern 'zufällig' sein.“, und er ist sachdienlich, weil er dazu beitragen kann, Anwender vor Fehlern im Umgang mit dem OTP zu bewahren. Gruß von --OS 07:29, 24. Okt. 2011 (CEST)

die passage ist natuerlich nicht falsch, sie stand nur an der falschen stelle, naemlich mitten in einem beispiel. das verfahren sollte im abschnitt "beschreibung" beschrieben werden, im abschnitt "beispiel" wird dann das beispiel durchgerechnet. in der beschreibung wird diese art der schluesselwahl bereits durch die forderung "gleichverteilt zufällig" ausgeschlossen. dort kann aber sicher noch ein hinweis eingefuegt werden, dass es sich bei einer solchen schluesselwahl dann nicht mehr um ein OTP, sondern ein Vigenère/Vernam handelt (analog zur Stromverschlüsselung bei nur pseudozufaelliger wahl); der angriff wird dort ja sicherlich bereits beschrieben. --Mario d 12:52, 24. Okt. 2011 (CEST)

Ich wiederhole: Bitte belege die Legitimität und Sinnhaftigkeit deiner Löschung anhand einer seriösen Literaturstelle, aus der hervorgeht, dass die Verwendung von Klartextpassagen als Schlüssel ausdrücklich empfohlen oder zumindest als unbedenklich angesehen wird, und nicht als im Widerspruch zur Forderung nach „Unvorhersagbarer Zufälligkeit“ des Schlüssels zur Verhinderung einer ansonsten gefährlichen Einbruchsmöglichkeit angesehen wird! Gruß von --OS 10:34, 28. Okt. 2011 (CEST)

die sinnhaftigkeit meiner loeschung liegt darin, dass die bemerkung an dieser stelle den artikel nicht verbessert, weil das verfahren bereits bekannt sein sollte, wenn man das beispiel liest. das beispiel soll ja nicht das verfahren ein zweites mal erlaeutern. falls du das anders siehst, koennen wir gerne eine dritte meinung einholen. --Mario d 11:46, 28. Okt. 2011 (CEST)

Versuch nicht dich herauszureden. Tatsache ist, du hast gelöscht und nicht verschoben. Bring den Beleg oder mach deine Löschung rückgängig. Gruß von --OS 08:07, 7. Nov. 2011 (CET)

ich habe oben, wo es hingehoert, einen satz mit dem wort "Textpassagen" eingebaut. --Mario d 12:03, 7. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Artikelüberarbeitungen durch Benutzer:MarioS

Hallo Mario, du hast dir die Freiheit genommen, den Text nach deinem Willen zu überarbeiten, so wie es dir gefällt, ohne die einzelnen Punkte auch nur ansatzweise zur Diskussion zu stellen. Nach deinen Umarbeitungen wimmelt der Artikel leider vor stilistischen, didaktischen und sachlichen Unstimmigkeiten. Außer der von dir eigenwillig durchgeführten Löschung des wichtigen Warnhinweises zur Vermeidung der fehlerhaften Verwendung von Textpassagen als Schlüssel (siehe Diskussionsbeitrag oben), kritisiere ich deine folgenden Artikeländerungen: 1) „Bei dem One-Time-Pad sind sowohl der Klartext, als auch der Schlüssel und das Chiffrat Worte der Länge $n$ über einem Alphabet.“ Abgesehen von stilistischen und didaktischen Schwächen deines Satzes, ist der von dir hier benutzte Begriff „Worte“, wenn er allgemeinverständlich benutzt wird, irreführend bis falsch. Er bedürfte einer Definition, die du aber nicht bringst. Aus Verständnisgründen wäre es daher besser – wenn man ihn schon nicht sauber einführt – auf seine ohnehin überflüssige Verwendung zu verzichten. Auch deine Formulierung „über einem Alphabet.“ wirkt unnötig verkomplizierend. Das alles kann man klarer, richtiger, verständlicher und besser ausdrücken als es dir gelungen ist. 2) „Das Alphabet ist in der modernen Kryptologie üblicherweise die Menge der Bits $\{0,1\}$, in der klassischen Kryptographie die Menge aller Großbuchstaben.“ Das gehört hier nicht hin und es ist so auch nicht korrekt. Besser wäre es, sich aus Verständnisgründen zunächst nur auf eine Methode zu konzentrieren (so wie ich es getan habe) und danach weitere zu erläutern. Sinnvoll ist es, sich zunächst der einfacheren zu widmen. Dabei handelt es sich um die chronologisch erste. Du verdrehst die Chronologie mit deinem Satz. Das ist didaktisch unklug. Darüber hinaus ist deine Aussage nicht korrekt, denn viel häufiger als Bits werden in der modernen Kryptographie Bytes als Grundlage für die Verschlüsselung gebraucht. Den Passus, der das erläuterte, hast du im Artikel gelöscht, was aus meiner Sicht keine Verbesserung darstellt. Ferner weißt du vielleicht, dass sich auch die klassische Kryptographie keinesfalls nur auf Großbuchstaben beschränkt. Durchaus häufig wurden auch Ziffern, Zahlen, Kleinbuchstaben oder sogar Silben verschlüsselt. 3) „Zur Verschlüsselung wird der Schlüssel zeichenweise modulo der Alphabetgrösse auf den Klartext addiert, bei der Verwendung von Bits entspricht das einer Exklusiv-Oder-Verknüpfung (XOR) der einzelnen Bits.“ Tut mir leid, dass ich deutlicher werden muss, aber diese pseudowissenschaftliche Formulierung ist weder Fisch noch Fleisch. Erkläre es bitte in gut verständlichen Worten oder anhand sauberer Mathematik oder lass es sein! Dieser Satz, so wie er ist, verbessert jedenfalls den Artikel nicht. 4) Über die von mir angegebenen Drei Punkte hinaus, hast du einen vierten Punkt formuliert, nämlich „Der Einmalschlüssel muss genauso lang sein wie die Nachricht„. Man kann darüber diskutieren, ob dieser Punkt hier aufgenommen werden muss oder, ob dies unnötig ist. Du hast aber nicht diskutiert, sondern ohne Diskussion geändert, noch dazu ohne große Sorgfalt und du hast damit die Konsistenz des Artikels verdorben. Nach meiner Ansicht muss dieser Punkt nicht hier und weiter unten immer wieder Erwähnung finden, denn er wurde bereits ganz zu Beginn des Artikels explizit als kennzeichnendes Merkmal des OTP eingeführt: „Kennzeichnend ist, dass ein Schlüssel verwendet wird, der (mindestens) so lang ist wie die Nachricht selbst.„ Du hast dir doch Vermeidung von Redundanz auf die Fahne geschrieben, wie man deinen Änderungskommentaren immer wieder entnehmen kann, oder? Warum hältst du dich nicht selbst daran und lässt es sein, redundante Aussagen in den Artikel mehrfach einzufügen? Und, wenn du denn schon einen vierten Punkt eigenmächtig aufnimmst, dann bitte nicht so, wie du es gemacht hast. Denn zum einen ist deine Aussage genaugenommen falsch, denn selbstverständlich darf der Schlüssel auch beliebig viel länger sein als die Nachricht. Zum anderen hast du weiter unten im Text diese Aufweitung auf vier Punkte nicht konsistent umgesetzt. Dort ist weiter von Drei Punkten zu lesen. Somit hast du durch deine Änderung auch den inneren Zusammenhang des Artikels gestört. 5) „Eng verwandt mit dem One-Time-Pad ist die Stromverschlüsselung, bei welcher der Schlüssel pseudozufällig erzeugt wird.„ Diese Aussage ist äußerst schwammig. Es macht kaum Sinn, hier das im Artikel beschrieben Verfahren mit einer ganzen Klasse als „Eng verwandt„ bezeichnen zu wollen. Das ist keine präzise Formulierung und wirkt eher irreführend als sinnvoll. Sage es bitte richtig oder gar nicht. Auch ist es kein kennzeichnendes Merkmal, weder des OTP noch von Stomchiffren, das dabei „der Schlüssel pseudozufällig erzeugt wird„, wie du es mit deinem unpräzisen Nebensatz suggerierst. In Summe kann ich damit keine Verbesserung des Artikels feststellen. Du hast den Artikel verschlechtert! Gruß von --OS 07:37, 24. Okt. 2011 (CEST)

1) die doppelbedeutung war mir vorher nicht aufgefallen, ich habe "worte" durch "zeichenketten" ersetzt und den begriff "alphabet" verlinkt.

2) ich kenne keine darstellung in der literatur, die bytes anstelle von bits verwendet, das waere auch nicht sehr sinnvoll und wuerde die darstellung verkomplizieren. im gesamten artikel verwenden wir grossbuchstaben, so wie in allen anderen klassisch orientierten beschreibungen des OTP, die ich kenne. daher das "üblicherweise". was wuerdest du denn lieber lesen? fuer "einfacher" halte ich uebrigens eine beschreibung auf der basis von bits; ich habe aber nicht vor, deshalb den artikel zu aendern, da der mehrwert doch eher gering waere.

3) was ist denn an dieser formulierung pseudowissenschaftlich? der satz ist jedenfalls korrekt, ob man an dieser stelle die modulo-addition einfuehren soll, kann sicherlich diskutiert werden.

4) der vierte punkt ist an dieser stelle sicherlich notwendig, denn sonst wird die folgerung im uebernaechsten satz falsch. warum damit die konsistenz des artikels verdorben sein soll, ist mir nicht klar. die einleitung darf mMn durchaus redundanzen zum rest des artikels enthalten, das ist aufgrund ihrer funktion sogar unvermeidlich. wie haettest du denn den vierten punkt eingefuegt? meine beschreibung stuetzt sich auf Buchmann, mir ist auch keine beschreibung des OTP bekannt, bei der der schluessel laenger ist als die nachricht; hast du dafuer eine quelle?

5) ich habe hier einen zusammenhang aufgezeigt, der sicherlich besteht. wie wuerdest du es denn "richtig" sagen? zum rest ein zitat aus der einleitung von Stromverschlüsselung: "Der Schlüsselstrom ist eine pseudozufällige Zeichenfolge." --Mario d 16:18, 24. Okt. 2011 (CEST)

...was fehlerhaft ist. Hab's dort richtiggestellt. Gruß von --OS 11:07, 28. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Unvorhersagbarkeit des Schlüssels

Hallo Mario, ein weiterer Fehler bei deiner Überarbeitung des Artikels ist dir unterlaufen, indem du den wichtigen Punkt „der Einmalschlüssel muss unvorhersagbar zufällig sein“ gelöschst hast und durch „gleichverteilt zufällig gewählt werden“ ersetzt hast. Auch diese Änderung wurde von dir ohne vorherige Diskussion durchgeführt und auch damit hast du den Artikel verschlechtert. Entscheidend ist nicht eine „Gleichverteilung“ der Zufallszeichen des Schlüssels, sondern ihre „Unvorhersagbarkeit“. Beispielsweise treten die einzelnen Ziffern in den Nachkommastellen der Zahl Pi gleichverteilt auf. Dennoch ist diese Ziffernfolge als Einmalschlüssel denkbar ungeeignet, weil leicht vorhersagbar. Gruß von --OS 10:25, 28. Okt. 2011 (CEST)

diese praezisierung ist eine klare verbesserung, denn "gleichverteilt zufaellig" ist erstens exakt definiert und zweitens genau die richtige und notwendige forderung. sie impliziert unverhersagbar. die ziffern von pi moegen gleichverteilt sein, aber sie sind sicherlich nicht zufaellig, deshalb auch vorhersagbar. --Mario d 11:52, 28. Okt. 2011 (CEST)

Du argumentierst in die völlig falsche Richtung. Ich habe niemals behauptet, die Nachkommastellen der Zahl Pi seien zufällig. Durch deine Löschung der wichtigen Forderung nach „Unvorhersagbarer Zufälligkeit“ des Schlüssels hast du das Verständnis des Textes immens verschlechtert. Deine Ansicht, „"gleichverteilt zufaellig" [...] impliziert unverhersagbar“, ist keinesfalls offensichtlich. Woher soll der Leser das wissen? Meine Formulierung ist deutlicher und verständlicher, also besser! Wo in unserer Wikipedia ist denn die von dir erwähnte „exakte Definition“ von „gleichverteilt zufaellig“ nachzulesen? Gruß von --OS 08:05, 7. Nov. 2011 (CET)

das lemma habe ich verlinkt und noch eine erklaerung nachgeschoben. --Mario d 12:00, 7. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)

Mit Zusatzinfos Entschlüsselung möglich

Quelle 1: Spiegel Online vom 24. November 2012: Taube mit Geheimbotschaft: Weltkrieg-Code ist nicht zu knacken Quelle 2: Spiegel Online vom 16. Dezember 2012: Brieftaube mit Geheimbotschaft: Historiker knackt Weltkrieg-Code --Agatha Bauer (Diskussion) 08:36, 18. Dez. 2012 (CET)

Wohl kein OTP (→ „Codebuch“, im Felde auch eher unpraktikabel). Korrekt angewendete One-Time-Pads sind ohne den Schlüssel nicht zu dechiffrieren – das ist so und wird auch so bleiben (hängt nicht von der Rechengeschwindigkeit des Computers o.ä. ab). Genauer gesagt, jeder beliebige Text ließe sich „entschlüsseln“ (siehe Artikel). Grüße, _{•  • hugarheimur} 08:52, 18. Dez. 2012 (CET)

Doch ein OTP (Spiegel Online vom 27. Dezember 2012: Geheimbotschaft aus Weltkrieg: Experten verzweifeln an Brieftauben-Code) und noch nicht Entschlüsselt. --Agatha Bauer (Diskussion) 15:03, 28. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Plankton314 (Diskussion) 15:17, 18. Feb. 2014 (CET)