Diskussion:Salt (Kryptologie)/Archiv

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:Salt (Kryptologie)/Archiv#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Diskussion:Salt_(Kryptologie)/Archiv#Thema_1

(nicht eingeordnete Diskussionsbeiträge

Ich habe im Rahmen meiner Änderung den Satz "Falls jemand in den Besitz des Wertes des Salzes und des gespeicherten Hashes kommt, so sind zwar Wörterbuchangriffe möglich, jedoch verdoppelt jedes Bit aus dem Wert des Salzes den benötigten Platz und die benötigte Zeit, um die Hashes einer Wörterbuchattacke zu berechnen." entfernt. Ich habe ihn nicht verstanden und vermute, daß der ursprüngliche Autor sich geirrt hat, denn der Absatz hat das eigentliche Thema nicht rübergebracht. Sollte ich mich geirrt haben, bitte den Satz wieder (evtl. umformuliert) hinzufügen. --AndreKR 02:47, 27. Jul 2006 (CEST)

Wieso verwendet man den Begriff salted Hash, übersetzt aber salt ins Deutsche? Ich meine sollte man nicht konsequenterweise von Salt reden? (bzw. von gesalzenem (versalzenen?) Hash)

Recht hast du... habs verschoben. --AndreKR 04:51, 25. Feb. 2007 (CET)

Verwendet man "der" oder "das" Salt im Deutschen? Ich bin also auf der Suche nach dem korrekten Artikel. MfG --Mweber 15:07, 5. Mai 2007 (CEST)

Im Allgemeinen verwendet man ja den Artikel der deutschen Übersetzung, hier als das Salz. --FGodard ✉ ^Bewertung 19:17, 24. Jun. 2007 (CEST)

überarbeiten

Das könnte man noch verständlicher formulieren. --194.245.91.129 15:59, 31. Jul. 2007 (CEST)

Oder besser noch bei der Gelegenheit mit dem Artikel Salted Hash verheiraten, denn ein Salt ohne Hash ist ziemlich nutzlos und die beiden Artikel sind bei weitem nicht zu lang dafür. -- Glue 18:21, 11. Nov. 2007 (CET)

Stimmt, ich hab's auch nicht verstanden, obwohl ich mich ein kleines bißchen mit der Thematik auskenne.--Poc

starke Ueberarbeitung des Artikels

Der Artikel wurde von mir in eine Form gebracht, die verstaendlich ist. Unnuetze und falsche Sachen (aka Absatz ueber rainbow table) wurden entfernt. Wenn hier Leute meinen, diese vollstaendige Neuschreibung des Artikels wuerde ihn nicht verbessern, ok. Ich habe leider kein weiteres offenes Zeitfenster um mich darueber zu unterhalten, IMO gibt es da nichts zu diskutieren wenn ein Artikel so offensichtlich schlecht geschrieben ist.

Der Abschnitt "Schutz vor Angriffen mit einer Rainbow Table" ist weder unnütz, da er wesentliche Informationen darüber enthält, warum Salts eingesetzt werden, noch enthält er meiner Meinung nach fachlich falsche Informationen. (Etwas unsicher bin ich mir nur bei der Begrenzung von Rainbow Tables auf acht Zeichen, die mir etwas wenig erscheint, bei meiner Recherche an anderer Stelle aber vielfach zu finden war.) Außerdem sollte man, falls man fachliche Fehler entdeckt, diese verbessern und nicht einfach den ganzen Abschnitt löschen. -- Novil Ariandis 11:26, 20. Sep. 2008 (CEST)

Im Beitrag rainbow table wird darauf bereits eingegangen, daher ist ein Abschnitt (mit solch einer Qualitaet (aka Passwort knacken, aka nicht mehr moeglich usw. eh nicht) nicht erforderlich. Ausserdem ist dies eine Begriffserklaerung, eine Motivation fuer den Einsatz einer Methode gehoert nicht in ein Lexikon. Deine jetzigen Anpassungen sind auch nicht gut. Der Salt und der Klartext muessen _nicht_ konkateniert werden, man kann auch KLARTEXT_A@SALT@KLARTEXT_B oder sonstwas machen. Ein Beispiel fuer einen Klartext (z.B. ein Passwort) ist ueberfluessig (DRY). Verweise auf Begriffe in Klammerung (Hashtabelle) mit vorheriger Erklaerung sind ebenso ueberfluessig (DRY). Ebenso ist es ueberfluessig zu erlaeutern, warum Woerterbuchangriffe nun komplexer sind (geht aus "Erhoehung der Entropie" hervor, ein interessierter Leser findet dort weitere Infos (DRY)). TLS ist eine Weiterentwicklung von SSL. SSL wird nicht weiterentwickelt (Aktualitaet).

Bitte mache dich erst einmal vertraut, wie gute Artikel bei der Wikipedia aussehen. Ein Artikel sollte alle notwendigen Informationen enthalten, damit ihn ein Laie verstehen kann. Daher sind die aufgeführten Erklärungen keinesfalls überlüssig. Ein gewisses Maß an Redundanz muss daher hingenommen werden. -- Novil Ariandis 12:09, 20. Sep. 2008 (CEST)

Moege sich dann jemand anders mit dir auseinandersetzen, mein Zeitfenster ist jetzt zu. Informiere du dich doch bitte vorab ausfuehrlicher ueber ein Thema, bevor du einem Laien suggerierst, ein Klartext und ein Salt fuehren zu einer sicheren Verschluesselung. Ich empfehle dir in Zukunft keine Themen mehr zu bearbeiten, die in den Bereit der IT-Sicherheit fallen. Das wird nichts, bleib bei den Tieren :) Auch bezweifel ich, dass ein Laie den urspruenglichen Artikel verstanden haette, im Gegenteil, er haette wohl (so wie ich) sehr oft dabei schmunzeln muessen. Und noch etwas, hoer doch bitte damit auf eigene Aenderungen zu sichten, das hinterlaesst einen faden Beigeschmack.

Und ich empfehle dir, dich erst einmal damit auseinanderzusetzen, dass gute Artikel in der Wikipedia so ausführlich wie nötig und nicht so kurz wie möglich sein sollten. Außerdem ist es unmöglich, wie du dich hier als Kryptographie-Experte aufspielst ohne Einblicke in deine Qualifikation zu geben. Von Sichtern bearbeitete Texte werden übrigens automatisch als "gesichtet" markiert. -- Novil Ariandis 12:21, 20. Sep. 2008 (CEST)

Das mit dem sichten war mir nicht bekannt, man das ganze ja voellig unbrauchbar. Egal. Krypto-Experte, das ist deine Fehl-Interpretation, wurde nirgends von mir geschrieben. Und du moechtest Qualifikationen sehen? Jetzt wird es ja amuesant. Irgendwas muss ich an dem Konzept hinter der Wikipedia missverstanden haben, ich werde meine Ansicht dazu ueberdenken. Nun aber einen schoenen Tag noch.

konkatenieren

Mir ist unklar, warum man im Einleitungssatz (oder überhaupt) mit Fremdwörtern kokettieren muss. Die Verständlichkeit für den Einsteiger schwindet dadurch deutlich und überflüssigerweise. Verknüpfen passt zudem deutlich besser als verketten, da keinesfalls nur eine einfache Aneinanderreihung (Verkettung) denkbar ist. -- 87.153.195.23 19:59, 3. Nov. 2009 (CET)

Rainbow Tables

Der letzte Satz im Abschnitt "Motivation" erweckt den Eindruck, Rainbowtables seien einfach gehashte Wortlisten. Das wäre dann doch zu stark vereinfacht. Ich schlage vor, diesen Satz einfach wegzulassen. Der dritte Satz im Abschnitt "Anwendungen" sollte aus sprachlichen Gründen dann so beginnen: Sogar Rainbowtable-Angriffe sind... -- Mak 01:16, 13. Jun. 2011 (CEST)

Historische Frage

Salts kamen zu einer Zeit in Mode, als von Rainbow-Tables auf Grund fehlender großer Massenspeicher noch keine Rede war. Frage: Wozu wurden Salts damals eingesetzt? (Soweit ich mich erinnere, wurden Salts erstmals zusammen mit einem aus DES erzeugten Trapdoor-Algorithmus eingesetzt.) --217.6.251.18 09:20, 12. Jul. 2011 (CEST)

Forensoftware?

Die Beispiele für die Anwendung von Salts sind derzeit zwei Protokolle (prinzipiell wichtig, auch wenn ich eines davon noch nie gehört habe), und dann gleich "Forensoftware" und schliesslich ganz allgemein "andere Systeme für Internetseiten". Wieso sind ausgerechnet Foren so prominent hervorgehoben? Salts sollten überall verwendet werden, wo Passwörter gespeichert werden. Bei Foren zumeist der Fall, klar, aber eben auch überall sonst, wo man sich registrieren kann oder muss (Mailprovider, Shops, Banken, ...). --y work? 17:08, 3. Jan. 2012 (CET)

Weiterhin ergeben mehrere gleiche Passwörter mit hoher Wahrscheinlichkeit unterschiedliche Hashwerte.

dieser sachverhalt wird 3x erklärt :-( (nicht signierter Beitrag von 79.226.0.121 (Diskussion) 16:46, 27. Jan. 2012 (CET))

Schutzwirkungen durch SALTs

Der Artikel legt z.Z. viel Wert auf die Aussage "Rainbowtables" werden wertlos etc. gelegt und Wörterbuchangriffe erschwert und damit wird suggeriert, das Hash-Verfahren mit SALTs in irgendeiner Form "an sich" sicherer sind. RTs funktionieren nur mit dem Hash-Verfahren, für welches sie gebildet worden sind. Wird dieses Verfahren verändert, kann man natürlich nicht Tabellen verwenden, welche für die eigentliche Version gebildet wurden. Rainbowtables haben einen Erstellungsaufwand, der um das 10-20 fache höher ist als denselben Zeichenraum zu bruteforcen - daher werden sie in der Regel eher für "Routine"-Bereiche erstellt oder von großen, kollaborativen Projekten für Zeichenräume, bei denen der einzelne Teilnehmer schon viel Zeit für einen Bruteforce verwenden muss. Liegt nun dasselbe Verfahren mit einem ordentlichen SALT vor, kann weiterhin der Zeichenraum, den RTs typischweise abgedeckt werden, gebruteforced werden. Ein einzelnes Passwort wird daher durch SALTs nicht besser geschützt.

Beim Bruteforcen steigt der Rechenaufwand gegenüber dem "Ur-Verfahren" nur, wenn mehrere geSALTete Hashes vorliegen. Dann muss jeder Passwort-Kandidat für jeden vorliegenden geSALTeten Hash berechnet werden und nicht ein einziges Mal erzeugt und dann verglichen werden. Je mehr Hashes vorliegen, desto langsamer wird das Bruteforcen bis es irgendwann nicht mehr wirtschaftlich wird. Daher wird eine Liste mit vielen geSALTetenHashes einfach aufgetrennt, nach interessanten Konten oder schlichtweg nach Menge, bis das einzelne System wieder mit einer angenehmen Geschwindigkeit arbeitet. Desweiteren können geSALTete Hashes, bei denen z.B. exakt das gleiche SALT vorliegt, zusammengefasst werden um den Aufwand wieder zu verringern. Passwortcracker machen das automatisch und hashen einen Kandidaten für jedes SALT nur einmal.

Wörtbuchangriffe

SALTs bieten keinen Schutz gegen Wörtbuchangriffe. Gute Wortlisten, selbst mehrsprachige, haben in der Regel weit unter 1 Milliarde Einträge, teilweise unter 50 Millionen. So viele Wörter und Namen, die Menschen auch als Passwort verwenden, gibt es dann doch nicht. Auch hier steigt nur der Rechenaufwand durch das SALT, aber die Zahl der zu prüfenden Kandidaten ist um vieles geringer als beim Bruteforcen. 50 Millionen Kandidaten können selbst bei einer Geschwindigkeit von 10.000 Kandidaten pro Sekunde in 83 Minuten geprüft werden. D.h. Probleme treten nur auf, wenn sehr viele geSALTete Hashes (i.S.v. tausende und mehr) auftreten. Aber auch hier kann die Aufgabe einfach auf mehrere Systeme verteilt werden, so dass z.B. 10 Systeme je 1000 geSALTete Hashes übernehmen und dann die Wortliste doch in akzeptabler Zeit durchbringen.

Alle erfolgreichen Verfahren wie MD5crypt und bcrypt verwenden daher einfach tausende von Iterationen desselben Hashing-Verfahrens um den Rechenaufwand in die Höhe zu treiben. Das ist die nützlichste Kombination mit einem SALT, nun können tatsächlich nur kleine oder sehr kleine Zeichenräume gebruteforced werden und auf Wortlisten können nur begrenzt Permutationsregeln angewandt werden. Aber letztlich gibt es kein Hashingverfahren, welches gegen Wort- oder Namenslisten resistent ist, daher sollte man nie von einem "Schutz" vor Wörtbuchangriffen beim Offline-Cracken sprechen. Vielleicht fieselt das jemand in den Artikel ein :) -- 88.67.75.65 11:52, 2. Mai 2010 (CEST)

Habe eben die Redundanz entfernt und auch einige inhaltliche Mängel ausgebügelt, es wird jetzt nicht mehr von verhindern, sondern nurmehr von erschweren gesprochen. Noch irgendwelche Anmerkungen? BTW: Salt schreibt man nicht SALT, da es keine Abkürzung ist. --FGodard|✉|± 13:42, 2. Mai 2010 (CEST)

Kollisionen

kryptographische hashfunktionen sind kollisionsresistent. schon bei MD5 braucht man im mittel 2^64 versuche um eine kollision zu finden. selbst wenn sich jeder der ca. 2^32 menschen auf der erde 100 passwoerter ausdenkt, ist die chance fuer eine einzige kollision bei all diesen passwoertern geringer als die fuer einen 6er im lotto. natuerlich muss es prinzipiell kollisionen geben - allerdings ist das schon nicht mehr so, wenn man annimmt, dass alle passwoerter weniger als 16 zeichen haben. deshalb bedeuten in der praxis gleiche hashwerte in der regel gleiche passwoerter - denn kollisionen zu finden ist eben ein extrem unwahrscheinliches ereignis, das in der praxis nie auftreten wird. --Mario d 22:52, 25. Apr. 2012 (CEST)

Ich weiß durchaus, dass Kollisionen sehr unwahrscheinlich und schwierig zu finden sind. Nur: Der Begriff "sehr unwahrscheinlich" heißt *nicht*, dass ein Ereignis nicht auftreten wird, sondern lediglich, dass man nichts darüber sagen kann, wann. Aber das ist eigentlich nicht das Wesentliche. Das Wesentliche ist, dass da eine falsche Aussage im Artikel steht. Nur weil in der Praxis eine Kollision selten vorkommt, ist das kein Grund, falsche Aussagen in den Artikel zu schreiben. Das hier ist ja kein sozialwissenschaftliches Seminar, wo jeder mal seine Meinung sagen kann und irgendwie haben ja alle recht, sondern Mathematik. Es gibt schlicht keine Rechtfertigung für Falschaussagen. Außerdem ist es *gerade* in der Kryptologie besonders wichtig, zu wissen, worauf man sich einlässt. Den einen Menschen, der aufgrund einer falschen Annahme Sicherheitsprobleme bekommt (oder was weiß ich noch alles), wird es nicht interessieren, dass dieser Ärger jetzt aber wirklich sehr unwahrscheinlich war.

In der aktuellen Version habe ich eine kleine Korrektur vorgenommen, so dass es jetzt inhaltlich stimmt. Auch deinen Ansprüchen sollte sie genügen, da sie schließlich darauf hinweist, dass es sich in der Praxis so verhält, wie du sagst. ʘχ (Diskussion) 01:34, 26. Apr. 2012 (CEST)

kollisionen kommen in der praxis nicht selten vor, sondern ueberhaupt nicht. hast du irgendeinen beleg dafuer, dass eine kollision mal zufaellig einfach so aufgetreten ist? bei MD5 kann man sie mittlerweile konstruieren, aber das ist nicht das gleiche. kryptographische hashfunktionen sind so gebaut, dass wir uns sicher sein koennen, dass kollisionen in der praxis nicht auftreten, eben weil die wahrscheinlichkeit dafuer so winzig ist. zitat Rüdiger Weis: "Eine Hash-Funktion bezeichnet man dennoch als kollisionsresistent, wenn der Rechenaufwand, eine Kollision zu finden, so riesig ist, dass man diesen als praktisch unmöglich ansehen kann."[1] er redet von finden, hier geht es nur um zufaelliges auftreten - bei passwoertern, die in der regel kuerzer sind als die ausgabe der hashfunktion. bevor du also woerter wie "Falschaussagen" in den mund nimmst, ueberpruefe bitte erstmal deine ueberzeugung. hier ist eine huebsche tabelle mit wahrscheinlichkeiten: en:Birthday attack. --Mario d 12:16, 26. Apr. 2012 (CEST)

Was Herr Weis als kollisionsrestistent bezeichnet, ist unerheblich für den Wahrheitsgehalt der Aussage, die dort im Artikel stand, Kollisionsresistenz heißt nämlich eben nicht, dass man von gleichen Hashwerten auf gleichen Klartext schließen kann. Eine unter irgendeinem Modell entstandene geringe Wahrscheinlichkeit, ist kein Beleg für das Nicht-Auftreten. Zudem: Wer sagt denn, dass sich noch keiner einen Spaß daraus gemacht hat, eine MD5-Kollision zu konstruieren und die als Passwort zu gebrauchen? Dagegen ist die aktuelle Formulierung völlig in Ordnung, gleiche Hashes deuten auf Gleichheit hin. --Chricho ¹ ² 17:43, 26. Apr. 2012 (CEST)

Ich kann es auch nur wiederholen: Das ist keine Sache von Belegen, Meinungen oder Überzeugungen. Es ist einfach falsch, zu behaupten, es sei in der Praxis unmöglich, dass die Hashes gleich sind trotz unterschiedlicher Passwörter. Statt dessen ist es korrekt, zu sagen, das komme selten vor. Und genau das steht ja jetzt auch im Artikel. (Ich weiß auch nicht, warum das jetzt problematisch sein soll.) ʘχ (Diskussion) 17:49, 26. Apr. 2012 (CEST)

PS: Habe gesehen, es steht nicht drin, dass es selten vorkommt. Habe es eingebaut. Jetzt sollte es doch wirklich ok sein. ʘχ (Diskussion) 17:53, 26. Apr. 2012 (CEST)

@Chricho: a) doch, genau das heisst es. wenn naemlich zwei unterschiedliche klartexte den gleichen hashwert haetten, waere das eine kollision. mit deiner argumentation haetten auch digitale signaturen keine beweiskraft; die haben sie aber, eben weil kollisionsresistenz bedeutet, dass es praktisch unmoeglich ist, kollisionen zu finden. b) neue kollisionen zu finden ist immer noch harte arbeit. hast du dir mal eine kollision angeschaut? hier ist der state of the art, eine kollision in 128 byte: [2]. zwei passwoerter zu finden, die kollidieren, waere eine sensation - und MD5 wird schon lange nicht mehr als sicher betrachtet.

@ʘχ was meinst du mit "Das ist keine Sache von Belegen"? es ist einfach falsch, zu sagen, es komme selten vor. das impliziert naemlich, dass es manchmal vorkommt. genauso koenntest du behaupten, dass es nur selten vorkommt, dass jemand einen 256-bit AES-schluessel raet. oder dass rosa elefanten nur selten vorkommen. deshalb sagt man einfach, das es in der praxis nie vorkommt. theoretisch gibt es diese wahrscheinlichkeit, sie ist allerdings vernachlaessigbar gering; das ist die bedeutung von in der praxis. --Mario d 12:12, 27. Apr. 2012 (CEST)

Versteh schon, was du meinst. Man muss es einfach nur richtig formulieren, dann ist es ja ok. Mit dem Satz "Es kommt selten vor" möchte ich in der Tat die Implikation verbinden, dass es manchmal vorkommt bzw. vorkommen kann. Denn das ist nun mal so. Die Tatsache, dass die Wahrscheinlichkeit vernachlässigbar gering ist, bedeutet eben nicht, dass es "praktisch nicht vorkommt". Es kommt praktisch vor, nur eben unheimlich selten. Halt so selten, dass man damit leben kann bzw. es in den meisten Fällen ignorieren darf. Und mehr kann man darüber auch schon nicht sagen. Das mit den rosa Elefanten ist hingegen Unsinn. Das ist eine Fehlinterpretation, denn du wirfst den intuitiven und formalen Wahrscheinlichkeitsbegriff durcheinander. Bei den Hashes geht es um den formalen, nicht den intuitiven (siehe [3]). ʘχ (Diskussion) 13:08, 28. Apr. 2012 (CEST)

woher nimmst du diese gewissheit, dass es praktisch vorkommt? ich glaube, du ueberschaetzt einfach die wahrscheinlichkeit. wenn sich jeder der 2^32 menschen auf der erde jeden tag ein neues passwort ausdenken muesste, dann erwarten wir nach mehr als 10 mio. jahren die erste kollision; nach 500 jahren ist die wahrscheinlichkeit immerhin schon fast in der groessenordnung einer sechers mit zusatzzahl im lotto. (bei konstanter bevoelkerung und angenommen, dass keine zwei passwoerter gleich sind). da benutzen wir aber vermutlich MD5 nicht mehr. das ist jetzt alles grob vereinfach und ueber den daumen gepeilt und soll auch nur die groessenordnungen veranschaulichen, aber man kann daraus folgern, dass mit extrem hoher wahrscheinlichkeit in der gesamten lebensdauer des universums kein einziges mal eine MD5-kollision zufaellig erzeugt wird (ohne ausserirdische). das mit den rosa elefanten ist eine anschauliche analogie. ich setze voraus, dass es eine mutation gibt, die die haut von elefanten rosa faerbt, so wie die von hausschweinen. die auftrittswahrscheinlichkeit dieser mutation ist extrem klein, aber nicht null. wuerdest du sagen, dass rosa elefanten selten sind? schwarze schwaene sind selten (ausserhalb von australien). menschen, die sechser im lotto haben und dann von einem auto ueberfahren werden, sind selten. rosa elefanten und zufaellige MD5-kollisionen sind zwar theoretisch moeglich, kommen in der praxis aber nicht vor. dafuer gibt es auch einen grund: kyptographische hashfunktionen sind speziell konstruiert um kollisionsresistent zu sein. eine hashfunktion, bei der man sich darum sorgen muesste, dass kollisionen zufaellig auftreten koennten, waere voellig ungeeignet. --Mario d 17:53, 28. Apr. 2012 (CEST)

Das sind letztlich philosophische Betrachtungen, die an der rein mathematischen Frage vorbeigehen. Die "Gewissheit" ergibt sich zwangsläufig, wenn man sich an die mathematischen Tatsachen hält. Und dabei überschätze ich die Wahrscheinlichkeit keineswegs. Wie winzig die ist, kann man sich ja leicht exakt ausrechnen. Das hat nur nichts mit der Frage zu tun: Sind zufällige Hashkollisionen möglich? Die Antwortet lautet: ja. Allerdings treten sie sehr selten auf. Deswegen darf man im sicherheitskritischen Bereich jetzt aber *nicht* von "praktisch unmöglich" ausgehen. Wenn man das tut, wie du ja schließlich, interpretiert man eine mathematische Wahrheit, und das ist kritisch, weil Interpretationen nur der persönlichen Intuition unterliegen und keinen objektiven Maßstäben. Deswegen vertete ich die Ansicht, dass ein enzyklopädischer Artikel zu mathematischen Themen sich Interpretationen nicht zu eigen machen sollte.

Wenn jetzt irgendein Leser für sich den Schluss zieht: "aha, Kollisionen sind also praktisch unmöglich", dann soll er das ruhig tun. Aber diese Interpretation sollte ihm nicht eingeredet werden. ʘχ (Diskussion) 11:06, 29. Apr. 2012 (CEST)

genau, denn mathematik trifft als formalwissenschaft keine aussagen ueber die wirklichkeit. kollisionen sind theoretisch moeglich, praktisch allerdings nicht. deshalb ist die aussage, sie traeten selten auf (mit der implikation, dass es manchmal passiert), schlicht falsch. mathematische wahrheiten sind keine aussagen ueber die welt, deshalb muessen sie interpretiert werden. nichts anderes machst du, wenn wenn du sagst, dass kollisionen "manchmal vorkommen". ingenieure machen das taeglich, das muessen sie auch. deshalb wird im sicherheitskritischen bereich natuerlich davon ausgegangen, dass kollisionen nie auftreten. nach deiner interpretation sind fragen wie "ist X moeglich?" sinnlos, denn aufgrund von moeglichen, aber extrem unwahrscheinlichen quanteneffekten muesste fuer jedes zukuenftige physikalische ereignis X (wie bspw. die rosa elefanten) die antwort "ja" lauten.

deiner im letzten satz geaeusserten ansicht handelst du uebrigens mit ausdruecken wir "selten" selbst zuwieder. da wir aber offensichtlich nicht weiterkommen, habe ich eine WP:3M angefragt. --Mario d 11:53, 29. Apr. 2012 (CEST)

(via WP:3M)Vorschlag zur Güte: schreibt irgendwas wie "eine Kollision tritt in der Praxis nur mit einer Wahrscheinlichkeit von maximal 1:10^xyz auf. Auf dem Wege habt ihr keine falsche Aussage im Artikel (denn die Aussage "es gibt keine Kollisionen" ist beweisbar falsch ...), aber dem Leser wird auch klar, wie unwahrscheinlich es ist, dass sie zufällig auftritt. --T3rminat0r (Diskussion) 12:16, 29. Apr. 2012 (CEST)

das waere prinzipiell eine gute loesung, allerdings ist das aus der geschlossenen formel fuer die wahrscheinlichkeit einer kollision bei n dokumenten nicht mehr direkt ersichtlich. "es gibt keine Kollisionen" habe ich nie behauptet, nur, dass sie praktisch unmoeglich sind. eine meinung, die ausser von Rüdiger Weis, den ich oben schon angefuehrt habe, auch von anderen geteilt wird:

• das BSI: "Collision resistance: Es ist praktisch unmöglich, zwei Nachrichten" [4]
• Stefan Lucks (prof an der uni weimar): "Kollisionsresistenz: Es ist praktisch unmöglich, eine Kollision zu finden [...]" [5]
• die firma von Jean-Jacques Quisquater: "collision resistance: it is practically impossible to find a pair of messages [...]" [6]
• Helmut Reiser (PD an der LMU): "Es ist praktisch unmöglich eine Kollision zu finden [...]" [7]
• die bundesnetzagentur: "H muss kollisionsresistent sein; d.h., es ist praktisch unmöglich, Kollisionen zu finden." [8]

das ist also gaengiger sprachgebrauch. nachtrag: ich habe eine version ohne das reizwort "praktisch unmoeglich" gefunden, mit der ich leben kann. ich hoffe, das thema ist damit erledigt. --Mario d 13:53, 29. Apr. 2012 (CEST)

Ich habe mal die Möglichkeit, dass die Passwörter trotz gleichem Hash unterschiedlich sind, mal noch eingefügt ;) Hoffe, dass passt dir so noch, und das Thema ist dann wirklich erledigt :) --T3rminat0r (Diskussion) 15:20, 29. Apr. 2012 (CEST)

meinetwegen, wenn es euch gluecklich macht. --Mario d 16:09, 29. Apr. 2012 (CEST)

@MarioS: Dass Mathematik keine Aussagen über die Wirklichkeit macht, stimmt völlig. Allerdings ist dein Satz "kollisionen sind theoretisch moeglich, praktisch allerdings nicht" dennoch falsch. Da gibt es wirklich nichts zu deuteln. ʘχ (Diskussion) 18:26, 29. Apr. 2012 (CEST)

Das Beispiel aus dem ersten Abschnitt ist gerade ein Punkt gegen "praktisch unmöglich". Denn trotz aller Unmöglichkeit habe ich hier ein Programm, dass ein ELF-Binary modifiziert um einen anderen, vorher wählbaren MD5-Schlüssel zu bekommen. Geziehlte Kollisionen sind also machbar, und nicht nur theoretisch. Die Tatsache, dass die Hashfunktionen gerne kollisionsfrei wären ist in der praxis eben nicht so. --P.C. ✉ 14:04, 11. Mai 2012 (CEST)

da du den abschnitt offenbar nicht ganz gelesen hast, hier nochmal ein relevanter auszug: "neue kollisionen zu finden ist immer noch harte arbeit. hast du dir mal eine kollision angeschaut? hier ist der state of the art, eine kollision in 128 byte: [9]. zwei passwoerter zu finden, die kollidieren, waere eine sensation - und MD5 wird schon lange nicht mehr als sicher betrachtet." das thema des abschnitts ist uebrigens das schliessen von hashkollisionen auf gleichheit der passwoerter, das hat mit gezielten kollisionen nur ganz wenig zu tun. wenn man aber nichtmal gezielt kollisionen in passwortlaenge finden kann, dann sind zufaellige erst recht kein problem. --Mario d 14:30, 11. Mai 2012 (CEST)

"Neue Kollisionen Finden ist harte Arbeit". Etwa so hart wie ein Programm ausführen. Oder eher: Trivial. Ja, bei Passworten mit fester Länge ist es schwerer, aber "unmöglich", dass zwei Passworte den selben Hash haben, das ist was anderes. --P.C. ✉ 17:15, 11. Mai 2012 (CEST)

genau, deshalb habe ich auch immer "praktisch unmoeglich" geschrieben. aber das steht ja oben bereits ausfuehrlich. natuerlich kann ich, gegeben eine kollision, mit minimalem aufwand beliebig viele weitere erzeugen. ich kann auch beliebig viele Wang-Yu-kollisionen erzeugen. "neu" wuerde ich das aber nicht nennen. geht es hier eigentlich noch darum, den artikel zu verbessern? --Mario d 17:54, 11. Mai 2012 (CEST)

angehängt oder vorangestellt?

Gleich am Anfang heisst es: "eine zufällig gewählte Zeichenfolge, die an einen gegebenen Klartext [...] angehängt wird" Meines Wissens wird das Salt vorangestellt. Also "hash_function($salt$plaintext)". (nicht signierter Beitrag von Dermaush (Diskussion | Beiträge) 21:52, 20. Nov. 2015 (CET))

Überarbeitung läuft

Wie dem geneigten Leser klar werden dürfte und auch der Konsens hier in vorgehenden Diskussionen lautet, bedarf dieser Artikel einer gehörigen Politur. Dieser werde ich mich den nächsten Tagen widmen. Bitte etwaige Fragen etc. hier mit sauberen Abschnitten vermerken. Für zeitnahes Feedback meinerseits bitte auf meiner Diskussionsseite eine Notiz hinterlassen. Danke. --Roeme (Diskussion) 17:02, 22. Mai 2012 (CEST)

Meiner Meinung nach ist der Artikel akzeptable, so dass die Überarbeiten-Vorlage entfernt werden könnte. Gibt es da einen Konsens? Joschi71 (Diskussion) 14:24, 14. Jun. 2013 (CEST)

Bin auch der Meinung, dass der Artikel nun ausreichend gut ist...C rall (Diskussion) 18:46, 30. Okt. 2013 (CET)

Missverständniss oder unwissenheit?

So wie ich den Sinn des ersten Satzes verstehe widerspricht der folgende ihm sofort. Im ersten Satz wird absolut gesagt das die Sicherheit nicht erhöht wird aber im folgenden Satz das Gegenteil bewiesen.

"Wenn der verwendete Salt einem Angreifer bekannt ist, erhöht er nicht die Sicherheit bei einem Angriff auf dieses Passwort. Ein schwaches Passwort kann also fast ebenso leicht mithilfe von Wörterbuch- oder Brute-Force-Angriffen entschlüsselt werden[4], es muss nur noch durchprobiert werden, an welcher Stelle des Passwortes der Salt angehängt wurde."

Meine Behauptung dabei ist, dass durch eine Erhöhung des Aufwandes ein Passwort zu entschlüsseln, die Sicherheit eines solchen steigt. Die Frage ist ob Sicherheit in dem Kontext in Beziehung mit dem Aufwand steht der Nötig ist das Passwort zu entschlüsseln, was ich bejahen würde.

Wenn der verwendete Salt einem Angreifer bekannt ist, erhöht er die Sicherheit bei einem Angriff auf dieses Passwort nur in sehr geringem Maß. Ein schwaches Passwort kann fast ebenso leicht mithilfe von Wörterbuch- oder Brute-Force-Angriffen entschlüsselt werden[4], es muss nur noch durchprobiert werden, an welcher Stelle des Passwortes der Salt angehängt wurde. --NichtAllwissender (Diskussion) 13:37, 24. Mär. 2016 (CET)

Ich gebe dir Recht, dass die Sicherheit vom Aufwand des Knackens abhängt. Ich finde nur den letzten Abschnitt in der neuen Version auch etwas missverständlich. Natürlich erhöht ein geheimer Salt die Sicherheit, weil er dann die Funktion eines Peppers hat. Ich fände eine Formulierung besser in dem Sinne "die Funktion des Salt basiert nicht auf seiner Geheimhaltung" oder "... setzt nicht seine Geheimhaltung voraus". Zu den schwachen Passwörtern: Die Position des Salt ist nicht das Problem und auch meistens bekannt, deshalb schlage ich vor, etwas in der Art zu schreiben "es muss lediglich das Passwort zusammen mit dem Salt durchprobiert werden."

--Beloumi (Diskussion) 10:52, 16. Apr. 2016 (CEST)

Entschlüsselt oder unverschlüsselt

"Wörterbuchangriffe durch Rainbow Tables werden erschwert, da nicht mehr in einer Liste von verschlüsselten Werten (Hashtabelle) der zugehörige entschlüsselte Wert nachgeschlagen werden kann, sondern für jeden Klartext hash (Klartext + Salt) = bekannter Hash überprüft werden muss, was viel Rechenzeit kostet. "

Warum heißt es hier, dass der "entschlüsselte" Wert nachgeschlagen wird ? Es handelt sich schlicht um Klartext aus einer eigenen Rainbow Table. Das Gegenteil von "verschlüsselt" ist nach meinem Verständnis "unverschlüsselt" und nicht "entschlüsselt". Es erschwert auch das Verstehen des Vorgangs. Ich hatte das gestern stillschweigend geändert, heute ist es zurückgesetzt. ? Gruß Matze (nicht signierter Beitrag von 178.201.21.117 (Diskussion) 10:22, 25. Mai 2016 (CEST))

hallo, vielen dank für deine mitarbeit. deine bearbeitung wurde nicht zurückgesetzt. änderungen von nicht angemeldeten benutzern müssen gesichtet werden, bevor sie angezeigt werden (s. WP:Gesichtete Versionen). das habe ich gerade getan. --Mario d 12:22, 25. Mai 2016 (CEST)

Ah ok. Danke :)

salt / pepper unverständlich

Ich bin nicht vom Fach aber interessiert. Ich verstehe anhand der Beschreibung den Unterschied zwischen salt und pepper leider nicht. Vielleicht mag das einer überarbeiten? Laut Beschreibung wird beides vor Erstellen des Hashes dem Passwort hinzugefügt. Wo ist dann der Unterschied? (nicht signierter Beitrag von 77.12.230.40 (Diskussion) 10:12, 14. Okt. 2019 (CEST))