Diskussion:Message-Digest Algorithm 5/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:Message-Digest Algorithm 5/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Message-Digest_Algorithm_5/Archiv#Thema_1

Wahrscheinlichkeit zwischen Verschiedenen Zeichenketten

Kann mir jemand erzählen wie man die Wahscheinlichkeit eines doppelten Vorkommens berechnet? Als Beispiel die Zeichenkette:

"Franz jagt im komplett verwahrlosten Taxi quer durch Bayern" ergibt a3cca2b2aa1e3b5b3b5aad99a8529074

Wann kommt es vor, das eine andere Zeichenreihenfolgen (die vielleicht sogar kürzer ist) die gleiche MD5 Summe ergibt? z.B.

"%(/&$$&DFD$$" wäre dann a3cca2b2aa1e3b5b3b5aad99a8529074

Denn die Aussage "(mit sehr großer Wahrscheinlichkeit)" im Artikel reicht mir nicht aus,

Vielen Danke im Voraus Anregungen -- Anonymous

Wenn du einen Hash hast und du nimmst irgendeinen zufälligen String, von dem du den Hash berechnest, dann ist die Chance nach "Gute Lösungen" durch "Mögliche Lösungen" (siehe Wahrscheinlichkeitsrechnung#Laplace-Experimente) 1/2^128 ~= 3E-39, dass beide Strings gleich sind. So wäre meine Sichtweise, ich lasse mich natürlich auch geren korrigeren, aber ich denke, dass es schon richtig sein sollte. --Martinpre 19:52, 25. Jun. 2007 (CEST)

Danke, das macht es schonmal nicht unmöglich. Aber bis morgen bekomme ich dann wohl nicht raus welcher stringwert == a3cca2b2aa1e3b5b3b5aad99a8529074 ist :-D. Nochmal frage zu der Berechnung: 1/2^128 ~= 3E-39. Die 128 sind ja 128bit, warum aber 1/2?. Wann wäre 1/2 denn 1/4? ;-). Dann hätte ich gerne noch 3E-39 in Tage umgerechnet *scherz*. -- Anonymous

Naja die Chance, dass ein Bit "stimmt" ist 1/2. Die Chance, dass zwei Stimmen ist 1/2^2 ...

Die 3E-39 sind hierbei nur die Chance, dass wenn du einen Hash hast und du einen zweiten aus einem zufälligen String berechnest gleich ist. lg noch ;) --Martinpre 19:04, 2. Jul. 2007 (CEST)

Ganz anderer eher theoretischer Ansatz (wenn falsch bitte korrigieren, habe die andere Antwort übrigens nicht verstanden): Beim md5-Hash wird aus einer beliebig langen Zeichenkette ein 128 Bit langer Wert erzeugt. Da es unendlich viele beliebig lange Zeichenketten gibt, allerdings nur begrenzt viele Möglichkeiten für einen 128-Bit-Wert (2^128 oder so) folgt daraus dass es unendlich viele Möglichkeiten gibt auf einen bestimmten Hash-Wert zu kommen. Wie gesagt das ist jetzt nur Theorie (wie immer wenn unendlich vorkommt), was in der Praxis machbar ist, ist eine andere Frage. lG -- auch (mehr oder weniger) Anonym^^

Natürlich gibt es unendlich viele Möglichkeiten auf einen Hash zu kommen. Zur Frage: 0,5¹²⁸ ≈ 2,93×10^-39. Das heißt, dass man ungefähr 10³⁸ Hashes durchtesten muss um auf den korrekten zu kommen. Falls man 10.000 Hashes pro Sekunde berechnen kann, braucht man rund 300 Quadrillionen (=Billionen Billionen) Jahre für das finden einer Kollision. Praktisch lässt sich zu einem Hash ein passender Klartext in wenigen Stunden ermitteln, sofern der Klartext beispielsweise nur aus Zahlen und Buchstaben besteht und auch recht kurz ist. Ein simples 8-Zeichen-Passwort ohne Sonderzeichen und ohne Salt lässt sich zum Beispiel mit Rainbow-Tables oder anderen optimierten Suchverfahren in wenigen Minuten bis Stunden aus dem gegeben Hash heraus wiederfinden. -- Jonathan Haas 20:46, 4. Jul. 2008 (CEST)

Einige Fragen

Ein sehr schöner Artikel, ich habe einige Fragen dazu, vielleicht können Sie beantwortet und dann in den Artikel übernommen werden:

warum sind überlegungen über die sicherheit von md5 wichtig? ich habe gedacht, dass md5 nur den zweck hat, dass man schnell überprüfen kann, ob eine datei/information, die man erhalten hat, diesselbe ist, wie sie ursprünglich erstellt wurde. das macht das suchen von derselben datei auf mehreren clienten, z.b. bei Edonkey erst möglich.

aus der bekanntgabe von md5 kann ich doch nichts über den inhalt der datei sagen. warum sind dann sicherheitsbedenken bei md5 wichtig?

außerdem: kann es nicht sein, dass zwei total unterschiedliche dateien ein und denselben hash-wert liefern? wie groß ist diese wahrscheinlichkeit? dann könnte es ja z.b. sein, dass beim parallelen downloaden über verteilte netzwerke, z.b. edonkey, auf meinem rechner versehentlich zwei (oder mehr) total unterschiedliche dateien in eine gedownloadete "datei" reingequetsccht werden. diese datei wäre dann datenmüll. ist ein solcher fehler wahrscheinlich?

danke, --Abdull 15:46, 22. Dez 2004 (CET)

Bei einer kryptografischen Hashfunktion wie MD5 geht es darum, möglichst wirkungsvoll zu verhindern, dass eine böswillige Person eine Datei erstellen kann, die den gleichen Hashwert wie eine gegebene Datei hat. Mit einer nicht-kryptografischen Funktion wie zum Beispiel CRC ist es sehr einfach, zum Beispiel zu einem in elektronischer Form vorliegenden Vertragstext ein Dokument zu erfinden, in dem genau das Gegenteil steht. Welchem Dokument soll man dann glauen? Weiterhin werden zum Beispiel Sicherheitszertifikate gerne mit Hashes abgesichert. Wenn die Hashfunktion einfach brechbar ist, kann sich ein Angreifer zum Beispiel für jemand anderen ausgeben. Es geht bei kryptografischen Hashfunktionen also immer darum, dass mit dem Hashwert bewiesen werden muss, dass irgendeine Datei "echt" ist. Dazu muss die Hashfunktion "sicher" sein, was bei MD5 inzwischen nicht mehr der Fall ist. Zu Deiner zweiten Frage: Dass zwei Dateien den gleichen Hashwert haben, ist bei 2¹²⁸ theoretisch möglichen Hashwerten unheimlich unwahrscheinlich. Es sei denn, die Hashfunktion ist nicht sicher und es gelingt, eine Datei so zu "trimmen", dass sie den gleichen Hashwert hat. Bei großen Dateien ist das mit MD5 heute noch immer unmöglich. Die Chinesen haben bei ihren MD5-Brechversuchen IMHO mit 1024-Byte-"Dateien" gearbeitet, in denen dann ein paar wenige Bits differierten. Jetzt bleibt mir noch zu sagen, dass ich kein Kryptograf bin... --Echoray 17:35, 22. Dez 2004 (CET)

http://www.cits.rub.de/MD5Collisions/ <-- zieh dir das rein, da sind 2 pseduo erstellte dokumente mit unterschiedlichen inhalt aber gleicher md5 sum --CHRiSNEW 14:30, 13. Jan 2006 (CET)

RainbowCrack

Für den Fall, dass nicht alle hier das Portal:Mathematik verfolgen: jemand hat einen Link auf eine Software namens RainbowCrack dort abgeladen. Möchte sich das jemand mal ansehen?--Gunther 15:44, 2. Apr 2005 (CEST)

Die Software hat IMHO dort nichts zu suchen. --Qbi 17:19, 4. Apr 2005 (CEST)

Frage:

Warum ergibt: echo "Frank jagt im komplett verwahrlosten Taxi quer durch Bayern" | md5sum

f98f6704a03727a9585e1ca62bc878e9

Was mache ich falsch ? Bei anderen md5 prüfungen klappt es prima (PHP,perl,online Prüfsummenberechner) --80.134.251.178 09:11, 8. Mai 2006 (CEST)

echo -n "..." --Gunther 09:22, 8. Mai 2006 (CEST)

Ich habe jetzt mal eingegriffen und die korrekten Werte eingetragen. Die standen auch schon mal drin, aber irgendwer hat wohl die Teststrings *mit* Newline durch den MD5 gedreht und damit falsche Werte ermittelt. Dass die jetzigen Werte richtig sind, wurde mit mehreren MD5-Implementierungen überprüft, unter anderem auch hier. Ich bin drauf gestoßen, weil ich gerade eine C++-Bibliothek baue und nichtsahnend die Selbsttests mit den Werten aus dem Artikel durchführen wollte, nur schlugen sie leider fehl ;( Die Kollegen im englischen Artikel haben übrigens richtig gerechnet ;) --Cgommel 12:43, 17. Jun. 2011 (CEST)

MD5-Cracker

Eine IP hat gerade einen Link auf einen "MD5-Cracker" eingesetzt. Wie soll denn sowas funktionieren? Es wird doch eine beliebig große Menge von beliebig großen Texten auf einen 128-Bit-Wert abgebildet. Damit ist eine Rückrechnung IMHO komplett ausgeschlossen. Es ist halt doch ein Hash und keine Verschlüsselung... --Eike 12:06, 21. Mai 2006 (CEST)

die üblichen webangebote arbeiten mit einer datenbank, die millionen bis milliarden hashes errechnet und speichert. zum thema cracken empfehle ich http://openwall.com/john Thomas Springer 19:23, 21. Mai 2006 (CEST)

Nett, aber kann für lange Wörter oder gar Sätze unmöglich funktionieren - jedenfalls nicht zuverlässig, höchstens zufällig. --Eike 22:59, 21. Mai 2006 (CEST)

Passwörter bestehen meist nur aus einem Wort und aus diesem Grund wurden diese Datenbanken erschaffen ;-) --87.79.237.110 20:33, 6. Mai 2013 (CEST)

Ohne Extrasoftware unter XP?

Muss man sich zur Prüfung von md5sum eine Extrasoftware laden oder geht das bei Windows XP mit Bordmitteln? --134.155.99.41 11:09, 17. Apr. 2007 (CEST)

Lies den Artikel nochmal, dann weist du's ;-) Ok, XP bring sowas nicht mit 23:09, 28. Apr. 2007 (CEST)

Das stimmt so nicht. Im .NET Framework gibt es neben vielen anderen kryptographischen Funktionen auch den MD5-Hash. Man sollte den Artikel dahingehend aktualisieren.

Abschnitt „Regenbogentabellen“

@Mannerheim: Du hast die Alternativbezeichnung Rainbow Table wieder in den Artikel aufgenommen. Diese Änderung habe ich rückgängig gemacht, mit der Begründung, dass die Alternativbezeichnung schon im verlinkten Artikel erwähnt wird. Daraufhin hast du wiederum meine Löschung rückgängig gemacht, mit der Begründung, dass meine Begründung nicht ausreichend wäre. Kannst du mir bitte erklären, was an dieser nicht ausreichend ist? --Stefan Birkner 11:25, 1. Mär. 2008 (CET)

Ganz einfach: der Begriff ist unüblich. Im Sinne eines stringenten Informationsgewinns widerspricht es der Usability; der Leser wird gezwungen, seine Zeit mit Nebensächlichem zu verschwenden. --Mannerheim 21:33, 9. Mär. 2008 (CET)

Der Begriff wird beispielsweise im Standardwerk Kryptografie von Klaus Schmeh verwendet. Meines Erachtens ist eine deutsche Bezeichnung der englischen vorzuziehen. Englische Begriffe sind für den Experten natürlich gewohnter und erschließen sich ihm wohl schnelle, doch Experten sind nicht das einzige Zielpuplikum für Wikipedia-Artikel. --Stefan Birkner 21:47, 9. Mär. 2008 (CET)

MD5 überhaupt nicht mehr sicher!

Guten Tag, ich hab mich gestern mit meinem Mathe-Nachhilfe-Lehrer unterhalten. Der macht gerade seine Diplomarbeit in Quantenkryptographie und hat mir gesagt, dass es durch einen bestimmen Algorithmus durch Quantencomputer möglich sei, MD5-Hashes zu knacken. Könnte dies vielleicht jemand im Artikel näher beschreiben, der Ahnung auch von dem Gebiet hat? Meines Erachtens wird in dieser Hinsicht nichts im Artikel erwähnt.

gruß, Nico

Ja, der Algorithmus dazu dürfte fertig in der Schublade liegen, aber es scheitert wahrscheinlich an der Anwendbarkeit auf der derzeit vorhandenen Quantencomputer-Hardware. Den allerneuesten Stand der Technik kenne ich nicht, habe aber immer noch das Zitat eines Experten von vor ca. zwei Jahren im Ohr: "Es ist inzwischen gelungen, die Zahl 15 auf einem Quantencomputer effektiv anzugreifen, zu faktorisieren". MD5 hat zwar wenig mit Faktorisierungsproblemen zu tun, aber wenn noch nichtmal das klappt, brauchen wir über Angriffe auf Hashes wohl gar nicht zu sprechen.

Wenn der Kollege natürlich etwas zum Thema beitragen kann, dann sprich ihn doch mal an, ob er hier was schreiben möchte. --Echoray 17:43, 20. Aug. 2008 (CEST)

Quantencomputer sind noch nicht praktisch verfügbar. Man kann heutzutage nur Quantencomputer bauen, die mit ein paar Bits umgehen können. Das ist vielzuwenig für praktische Anwendungen. --Stefan Birkner 10:52, 21. Aug. 2008 (CEST)

Hallo Echoray, bist du dir sicher, dass du dieses "Zitat" richtig behalten hast!? Die Zahl 15 zu faktorisieren kann jawohl jeder fünftklässler. Bspw Primfaktorzerlegung: 15 = 3 * 5 Wozu du da einen Quantencomputer brauchst oder was daran "neu" sein soll, will mir nicht einleuchten...

Klar, um die 15 zu faktorisieren braucht man keinen Computer. Der Knackpunkt liegt aber, wie Stefan Birkner schrieb, darin, dass heutige Quantencomputer nur mit ein paar ganz wenigen Bits umgehen können. Die Zahl 15 kann man mit nur 4 Bit darstellen, deswegen ist sie wohl ein lohnenswertes Zwischenziel. Ich weiß inzwischen wieder, wer das mit der Zahl 15 wann gesagt hat: Rüdiger Weis, damals Cryptolabs Amsterdam, auf dem 20C3-Kongress 2003 in Berlin. Okay, ich habe mich um 3 Jahre verschätzt... Hier ein Audiomitschnitt des Vortrags, spult mal ca. zur Minute 3:50, da fällt das Zitat: ftp://ftp.ccc.de/congress/2003/audio/20c3_546_1024bit-RSA-ist-unsicher.ogg --Echoray 22:37, 1. Jan. 2009 (CET)

Wozu Quantencomputer? Playstations können das auch ganz gut: [1] --Bountin 13:26, 2. Jan. 2009 (CET)

http://md5cracker.org/index-page-cracken.html (nicht signierter Beitrag von 217.9.113.155 (Diskussion | Beiträge) 16:41, 28. Jul 2009 (CEST))

Fehler

Sollte es statt "Die Kollisionsfreiheit von Algorithmen ist daher eine schwächere Forderung als die Fälschungssicherheit eines Hashwertes." nicht heissen: "Die Kollisionsfreiheit von Algorithmen ist daher eine stärkere Forderung als die Fälschungssicherheit eines Hashwertes." Highlander 16:40, 21. Jun. 2009 (CEST)

Nein, das ist schon richtig so: Wenn ich nur ganz zufällig ein Dokument auffinde, dass den selben Hashwert wie ein zweites Dokument mit anderem Inhalt hat, dann ist das nicht ganz so schlimm. Wenn ich dagegen mit wenig Aufwand mir ein Dokument zurechtfälschen kann (mit Inhalten nach meinem Willen), dass den selben Hashwert wie ein zweites Dokument hat, dann ist das eine Katastrophe, weil ich damit lügen und betrügen kann. Deshalb wiegt die Fälschungssicherheit schwerer. --Echoray 17:51, 21. Jun. 2009 (CEST)

Algorithmus falsch

„Die Ausgangsnachricht wird zunächst so aufgefüllt, dass ihre Länge 64 Bits davon entfernt ist, durch 512 teilbar zu sein. Als erstes wird eine Eins angehängt, dann so viele Nullen wie nötig. In dem unwahrscheinlichen Fall, dass die Ausgangsnachricht schon die gewünschte Länge besitzt, wird trotzdem eine Eins angehängt. Nun wird eine 64-Bit-Zahl, die die Länge der Ausgangsnachricht repräsentiert, angehängt. Die Nachrichtenlänge ist jetzt durch 512 teilbar.“ Ausgangssituation: Die Nachricht ist bereits 64 Bits davon entfernt, durch 512 teilbar zu sein. Laut Artikel wird nun trotzdem eine 1 angehängt. Dazu kommen die 64 Bit der Längenangabe und fertig ist.... eine Nachricht, deren Länge eben nicht durch 512 teilbar ist... Im englischen Wikipedia-Artikel wird der Umstand, dass bei einer Nachricht der Länge 448 mod 512 dennoch eine 1 angehängt wird, übrigens gar nicht erwähnt. Da ich nicht weiß, was nun richtig ist (allerdings ist offensichtlich, dass die aktuelle Beschreibung schlichtweg falsch ist), ändere ich nichts, aber da sollte sich unbedingt mal jemand drum kümmern. 131.234.101.24 09:45, 21. Jan. 2010 (CET)

Ist mir beim Durchlesen des Artikels eben auch aufgefallen. Allerdings kenne ich mich nicht gut genug aus um eine Aussage darueber machen zu koennen wie nun korrekt verfahren wird. Kann sich dam bitte jemand annehmen? --Chromate 00:31, 21. Jul. 2010 (CEST)

MD5 unsicher

Unter http://www.heise.de/newsticker/meldung/Autor-haelt-md5crypt-nicht-mehr-fuer-sicher-1614781.html wird berichtet, dass der Autor Poul-Henning Kamp selbst seinen Algorithmus als nicht mehr sicher erachtet. Es wäre schön, wenn das jemand in den Artikel einarbeiten könnte wahlweise unter Sicherheit oder Geschichte. Sinnvoll wäre es natürlich die ursprüngliche News zu benutzen. Grüße --84.188.111.166 12:33, 10. Jun. 2012 (CEST)

da gehts um md5crypt, nicht um MD5. --Mario d 13:31, 10. Jun. 2012 (CEST)

Entschudigung, das habe ich so nicht gewusst. Dann kann diese Anfrage ja ad acta gelegt werden. Nur so aus Interesse: Was ist der unterschied (theoretisch, nicht in der Anwendung) zwischen md5 (hash) und md5crypt --84.188.111.166 19:37, 10. Jun. 2012 (CEST)

kein problem. md5crypt ist eine einwegfunktion, die auf MD5 basiert: "MD5 crypt hashes the password and salt in a number of different combinations to slow down the evaluation speed. Some steps in the algorithm make it doubtful that the scheme was designed from a cryptographic point of view--for instance, the binary representation of the password length at some point determines which data is hashed, for every zero bit the first byte of the password and for every set bit the first byte of a previous hash computation." [2] --Mario d 20:36, 10. Jun. 2012 (CEST)

Pseudocode k[i]

Es werden die k[i] definiert, später wird aber auf k(i) zurückgegriffen. Sollte man hier nicht eine einheitliche Notation verwenden? --Jobu0101 (Diskussion) 16:13, 1. Jul. 2012 (CEST)

erledigt --Mario d 11:43, 2. Jul. 2012 (CEST)

Analysen

Zitat: Der Angriff der chinesischen Forscher basierte auf Analysen.
Hier scheint etwas zu fehlen. Welche Analysen sind gemeint? Die Tatsache, dass die chinesischen Forscher MD5 analysierten, bevor sie einen Angriff starteten, ist sozusagen selbsterklärend...
--87.180.151.12 11:57, 13. Sep. 2014 (CEST)

ich habe den satz mal rausgenommen, wenn jemand den abschnitt ausbauen moechte, kann er das auch so. --Mario d 14:39, 25. Sep. 2014 (CEST)

Gilt das noch?

Zitat aus dem Artikel (relevantes fett): "Da noch kein erster Preimage-Angriff bekannt ist, sind in der Vergangenheit signierte MD5-Hashes aktuell (2013) noch sicher."

Gilt das noch? Kann man da bedenkenlos 2022 eintragen? --2003:DE:F3F:9000:5FD:406C:3D2D:3F47 21:34, 22. Feb. 2022 (CET)

Ich halte die Aussage für fahrlässig. Es ist Konsens, dass der Algorithmus hinüber ist. Selbst wenn noch kein Preimage-Angriff öffentlich bekannt wäre, wäre das Risiko für geheim gehaltene Preimage-Angriffe zu hoch. Zudem ist bereits seit 2009 ein Preimage-Angriff bekannt, der mit einer Komplexität von 2^123 zwar teuer und theoretisch ist, aber womit die Sicherheitseigenschaft formal widerlegt ist. --Matthäus Wander 23:36, 22. Feb. 2022 (CET)

Sicherheitsüberlegungen

Der Abschnitt "Sicherheitsüberlegungen" muss mal neu durchstrukturiert und aktualisiert werden. Teilweise widerspricht sich der Inhalt des Artikels inzwischen selbst. Insbesondere ist MD5 ja nun geknackt worden, man kann auf entsprechender Hardware im Minutentakt Kollisionen finden. Der gestern Abend neu eingefügte Satz "Insbesondere ist es noch nie gelungen, aus einer gegebenen MD5-Summe die Ursprungsnachricht zu rekonstruieren" ist irgendwie sachlich verkehrt. Aus einem 128-Bit-Hash kann ich wohl kaum "die" Ursprungsnachricht rekonstruieren, sondern nur per Kollision eine (möglicherweise Garbage enthaltende) Nachricht finden, die den gleichen Hash hat. --Echoray 15:28, 7. Sep 2004 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:44, 4. Feb. 2023 (CET)

Toter Link

Hallo Leute der unterste Link --> http://www.dseitz.de/md5 ist anscheinend tot. lg Tommy

"C++-Beispielimplementierung mit deutschsprachigen Kommentaren" http://www.ben-newman.de/com/MD5.php dito (nicht signierter Beitrag von 87.185.52.172 (Diskussion) 21:55, 27. Jan. 2011 (CET))

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:45, 4. Feb. 2023 (CET)

Aufbau von md5 Dateien

Gibt es schon Regeln darüber, wie md5 Dateien aufzubauen sind, in denen dann die md5 Hashes stehen?

Was für Regeln meinst du? In einer .md5 steht in der Regel einfach die MD5-Summe der Ursprungsdatei. Aber man kann dort auch anderes reinschreiben. --Qbi 15:22, 17. Jun 2005 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:46, 4. Feb. 2023 (CET)

Unlogisch?

"MD5 ist ein Vertreter aus einer Reihe von Hash-Funktionen, die von Professor Ronald L. Rivest am Massachusetts Institute of Technology entwickelt wurden. Als Analysen ergaben, dass der Vorgänger MD4 wahrscheinlich unsicher ist, wurde MD5 1991 als sicherer Ersatz entwickelt."

Dieser Satz ist finde ich ein wenig unlogisch - der Vorgänger (von MD5?!) MD4 ist unsicherer und deshalb wurde MD5 entwickelt? - Ist da eventuell von MD3 oder so die Rede?

Die Unlogik ist mir nicht klar. Rivest erkennt, dass MD4 unsicher ist, und entwickelt daher den (vermeintlich sicheren) Nachfolger MD5. --Matthäus Wander 12:49, 4. Feb. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:49, 4. Feb. 2023 (CET)

Abschnitt Sicherheitsüberlegungen / Unterpunkt Die Analyse-Methode

Die Überschriften haben mich etwas stutzig gemacht. Eventuell sollte "Sicherheitsüberlegungen" noch irgendwie mit "Angriffsmöglichkeiten" oder "Angiffsmethoden" in Verbindung gebracht werden, um einen besseren Zusammenhang zu den Unterpunkten herzustellen oder ein komplett neuer treffenderer Begriff für die Absatzüberschrift gesucht werden.

Ebenfalls sollte am Anfang des Abschnitts mit einem (einzigen) Satz deutlich gemacht werden was genau "kryptografisch (un)sicher" bedeutet oder ein Artikel der das klärt dazu verlinkt werden.

Außerdem hat mich folgender Satz irretiert: "Kollisionen finden heißt, man kennt ein M (Text) und sucht ein M' (Kollision), so dass hash(M) = hash(M') (dies wäre eine Fälschung)." Handelt es sich bei dieser Formulierung nicht schon um einen einen Preimage-Angriff und nicht nur um einen Kollisionsangriff? Die genaue Abgrenzung der beiden Angriffen scheint schwierig zu sein. Soweit ich das Verstanden habe hat das chinesische Wissenschaftlerteam keine Preimage-Angriffe durchgeführt.

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:49, 4. Feb. 2023 (CET)

Pseudocode

Folgender Pseudocode, welcher vormals in den Artikel eingebunden war, beschreibt SHA-1 und nicht MD5 (Initialisierungswerte habe ich jetzt schon ausgebessert). Aber K(i) kommt sicherlich nicht vor in MD5. Siehe RFC1321MD5 (nicht signierter Beitrag von 193.171.62.124 (Diskussion) 14:59, 30. Mai 2007)

Ich habe die Initialisierungswerte angepasst da sie nicht im little-endian Format waren. Jetzt gibt es auch den Richtigen Hash Werte wenn man den Pseudocode Implementiert. (6 Stunden Fehleranalyse :-() :-) (nicht signierter Beitrag von Timo.poppinga (Diskussion | Beiträge) 13:42, 12. Sep. 2007)

Es folgt der Pseudocode für den MD5-Algorithmus.

// Beachte: Alle Variablen sind vorzeichenlose 32 Bit-Werte und
// verhalten sich bei Berechnungen kongruent (≡) modulo 2^32

// Definiere r wie folgt:
var int[64] r, k
r[ 0..15] := {7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22}
r[16..31] := {5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20}
r[32..47] := {4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23}
r[48..63] := {6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21}

// Verwende den binären Vorkommateil vom 2^32-fachen Betrag des Sinus
// von Integerwerten als Konstanten:
für alle i von 0 bis 63
    k[i] := floor(abs(sin(i + 1)) × 2^32)

// Initialisiere die Variablen:
var int h0 := 0x01234567
var int h1 := 0x89ABCDEF
var int h2 := 0xFEDCBA98
var int h3 := 0x76543210

// Vorbereitung der Nachricht 'message':
var int message_laenge := bit_length(message)
erweitere message um bit "1"
erweitere message um bits "0" bis Länge von message in bits ≡ 448 (mod 512)
erweitere message um message_laenge als 64-Bit little-endian Integer

// Verarbeite die Nachricht in aufeinander folgenden 512-Bit Blöcken:
für alle 512-Bit Block von message
    unterteile Block in 16 32-bit little-endian Worte w(i), 0 ≤ i ≤ 15

    // Initialisiere den Hash-Wert für diesen Block:
    var int a := h0
    var int b := h1
    var int c := h2
    var int d := h3

    // Hauptschleife:
    für alle i von 0 bis 63
        wenn 0 ≤ i ≤ 15 dann
            f := (b and c) or ((not b) and d)
            g := i
        sonst wenn 16 ≤ i ≤ 31 dann
            f := (d and b) or ((not d) and c)
            g := (5×i + 1) mod 16
        sonst wenn 32 ≤ i ≤ 47 dann
            f := b xor c xor d
            g := (3×i + 5) mod 16
        sonst wenn 48 ≤ i ≤ 63 dann
            f := c xor (b or (not d))
            g := (7×i) mod 16
        wenn_ende
 
        temp := d
        d := c
        c := b
        b := ((a + f + k(i) + w(g)) leftrotate r(i)) + b
        a := temp

    // Addiere den Hash-Wert des Blocks zur Summe der vorherigen Hashes:
    h0 := h0 + a
    h1 := h1 + b 
    h2 := h2 + c
    h3 := h3 + d

var int digest := h0 append h1 append h2 append h3 //(Darstellung als little-endian)

Beachte: Anstatt der Original-Formulierung aus dem RFC 1321 kann zur Effizienzsteigerung Folgendes verwendet werden:

(0  ≤ i ≤ 15): f := d xor (b and (c xor d))
(16 ≤ i ≤ 31): f := c xor (d and (b xor c))

Sind Sie sicher, dass der Code stimmt? Der 5-Zeilen-Block, wo "temp gleich d" wird (ff) kommt mir merkwürdig vor. Ich habe das RFC 1321 gerade vor mir und kann nichts von einer Vertauschung/Rotation der Werte a,b,c und d finden. --The_MKay 14:43, 13. Jul. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 16:14, 4. Feb. 2023 (CET)

Wie überprüfe ich die MD5-Summe?

Hallo!

Ich bin ein Computerlaie, habe also Probleme so einfach mal schnell eine Überprüfung der MD5-Checksumme vorzunehmen. Wie muss ich verfahren um die Prüfung durchzuführen? Welche Programme benötige ich dafür?

Ich habe die Datei (ISO-Image, 314 MB groß) und die MD5-Checksumme.

Ich finde, diese Fragen sind durchaus für die Mehrzahl der Leser interessant, da insbesondere Laien mit Kryptografie und Hash-Werten Schwierigkeiten bei der Anwendung haben. Ich finde, dass in einen Wiki-Artikel auch beschrieben werden sollte, wie die MD5-Prüfung vorzunehmen ist.

Wer kann dies in den Wiki-Artikel einfügen? Betbuster 15:25, 10. Jul. 2007 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:51, 4. Feb. 2023 (CET)

Lord Koxinga 16:03, 2. Sep. 2008 (CEST)

zu Geschichte, erster Absatz, Ende: sollte da nicht stehen ...in MD5 gefunden.

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:52, 4. Feb. 2023 (CET)

Bildunterschrift aus der englischen Wikipedia

Beim Diagramm habe ich die Bildunterschrift der englischen Ausgabe übersetzt. Damit stammt der Text nicht von mir, erleichtert aber meiner Meinung nach das Verständnis des Diagramms. Bitte entschuldigt, wenn ich damit gegen die Nutzungsbedingungen verstoßen haben sollte. Ich wollte nicht vandalieren. -- 80.136.218.64 19:04, 9. Jan. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 16:20, 4. Feb. 2023 (CET)

Pseudocode

Hallo, weiß jemand, wie man diese Leerzeilen zwischen den Codeblöcken entfernen kann? -- Live Long and Prosper Motte001 • Diskussion • 21:28, 15. Apr. 2016 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:55, 4. Feb. 2023 (CET)

Windows MD5 Hash

Windows besitzt durchaus ein von Haus gelieferten MD5 hasher für Dateien. Von der Konsole über den Befehl CertUtil -hashfile filename MD5 zu erreichen

https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx#BKMK_hashfile (nicht signierter Beitrag von 109.91.14.45 (Diskussion) 17:01, 19. Okt. 2016 (CEST))

Archivierung dieses Abschnittes wurde gewünscht von: --Matthäus Wander 12:55, 4. Feb. 2023 (CET)

Schnorr-Signatur in der Einleitung

Ein Hinweis auf Schnorr-Signaturen ist im Abschnitt Message-Digest_Algorithm_5#Sicherheit enthalten, wo der Begriff der Kollisionsresistenz erläutert wird. Der Einleitungstext sollte die wichtigsten Fakten über den Artikelgegenstand MD5 enthalten, nicht über Schnorr-Signaturen, die einen eigenen Artikel haben. Wenn Signaturverfahren in der Einleitung genannt werden, dann sollten es eher RSA oder DSA sein, da diese in Kombination mit MD5 wesentlich verbreiteter waren als Schnorr-Signaturen. --Matthäus Wander 11:50, 5. Feb. 2023 (CET)

Nur mit der Schnorr-Signatur kann MD5 benutzt werden, weil RSA, DSA und auch das Elgamal-Signaturverfahren erfordert eine kollisionsresistente Hashfunktion. --Franz Scheerer aus Wiesbaden (Diskussion) 19:40, 6. Feb. 2023 (CET)

Die Antwort geht an meiner Argumentation vorbei. MD5 wurde mit RSA und DSA eingesetzt. --Matthäus Wander 21:00, 7. Feb. 2023 (CET)

Bei RSA und DSA wird die Signatur allein aus dem Hashwert der Nachricht berechnet, so dass die Signatur unverändert gültig bleibt für eine veränderte Nachricht mit identischem Hashwert. Die mit MD5 und RSA oder DSA erstellte Signatur gilt auch für mögliche Kollisionen zu der Nachricht. Damit ist die Signatur nicht sicher. Dies gilt bei den damals gebräuchlichen Schlüssellängen bei RSA und DSA allerdings ohnehin. --Franz Scheerer aus Wiesbaden (Diskussion) 21:19, 7. Feb. 2023 (CET)

Ist heute nicht sicher, wurde damals trotzdem eingesetzt. --Matthäus Wander 21:33, 7. Feb. 2023 (CET)

Damit bin ich einverstanden, wenn die Schnorr-Signatur im Artikel weiterhin erwähnt wird. --Franz Scheerer aus Wiesbaden (Diskussion) 10:17, 8. Feb. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Ilse Ongkim (Diskussion) 13:04, 2. Apr. 2023 (CEST)

Einleitung

Bitte Kürzung der Einleitung begründen. --Matthäus Wander 09:21, 17. Mär. 2023 (CET)

Alle wichtigen Informationen sind nach wie vor im Artikel zu finden. Aus meiner Sicht wurde nichts Wesentliches aus der Einleitung entfernt. Eine lange Diskussion der Sicherheit gehört nicht in die Einleitung. --Franz Scheerer aus Wiesbaden (Diskussion) 10:57, 17. Mär. 2023 (CET)

Dass MD5 als unsicher gilt und von der Verwendung abgeraten wird, ist eine wesentliche Information, die in die Einleitung gehört. Die Einleitung ist auch nicht zu lang − dazu muss man nur die Länge der Einleitung mit dem Abschnitt Message-Digest_Algorithm_5#Sicherheit vergleichen. --Matthäus Wander 09:25, 18. Mär. 2023 (CET)

Entscheidend für mich persönlich, es gibt keinen erfolgreichen Preimage-Angriff. Dies gilt unverändert nach mehr als drei Jahrzehnten! Aber ok, die Einleitung kann so bleiben. Ich habe kein Problem damit. --Franz Scheerer aus Wiesbaden (Diskussion) 10:09, 19. Mär. 2023 (CET)

Es spielt keine Rolle oder es ist sogar vorteilhaft, wenn MD5 als kryptographisch vollkommen ungeeignet gilt. Wir können es trotzdem verwenden, denn idealer Weise weiß niemand, welche Verfahren zur Kryptographie wir nutzen. Es sollte also nicht groß KRYPTOGRAPHIE GEEIGNET darauf stehen. Die Einleitung kann bleiben. --Franz Scheerer aus Wiesbaden (Diskussion) 18:39, 19. Mär. 2023 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Ilse Ongkim (Diskussion) 13:04, 2. Apr. 2023 (CEST)

Cracker mit GPU

http://www.elcomsoft.com/md5crack.html schafft angeblich 600 Mio "Passwörter" pro Sekunde, die richtige Grafikkarte vorrausgesetzt. Ist das erwähnenswert?--134.147.252.130 15:08, 28. Aug. 2008 (CEST)

Ein Tool von vielen. oclHashcat und John the Ripper halte ich für relevanter. --Matthäus Wander 16:18, 4. Feb. 2023 (CET)

Missverständnis unter "Sicherheitsüberlegungen"?

Hallo, da hat es wohl eine Art Verwechslung gegeben:

"Ein 2009 durchgeführter Test des Computermagazins c’t unter Verwendung von GPGPU ermöglicht es einem etwa ein Jahr alten Highend-Spiele-PC mit zwei Nvidia GeForce 9800 GX2 (insgesamt vier Grafikprozessoren), in knapp 35 Minuten eine Kollision zu finden."

Das war ein Artikel über GPU-Passwortcracken, d.h. hier ist ein Bruteforcer (konkret BarsWF, weil er bunt ist) eingesetzt worden. Dieser findet keine Kollisionen, sondern vergleicht die Hashes von selbst generierten Passwortkandidaten mit der vorliegenden (Passwort-)hash. Sind diese identisch, dann wurde das Passwort gefunden. Das angesprochene Problem ist der vergleichsweise niedrige Rechenbedarf von MD5 und dennoch die allgemeine Verwendung als Passwortschutz, trotz besserer Alternativen wie MD5(crypt) usw. usw. die teilweise bereits 1999 vorgestellt wurden, siehe z.B. hier. --217.91.183.160 19:11, 4. Feb. 2010 (CET)

Ich habe versucht den Satz zu korrigieren, scheitere aber am Verständnis, was genau in 35 Minuten gelungen ist: ein Passwort wiederherstellen... welcher Länge und Eigenschaften? Der Satz ist jetzt entfernt. --Matthäus Wander 12:43, 4. Feb. 2023 (CET)