Diskussion:Message-Digest Algorithm 5

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 25 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

Zum Archiv

Wie wird ein Archiv angelegt?

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)

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))

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)

Sicherheit und Einsatzzweck

Sicherheitsaussagen machen i.d.R. nur dann Sinn, wenn die Anwendung dazu genannt wird. Der MD5-Crack geschieht auf zwei hintereinander liegenden Eingabesequenzen, spielt sich also auf 1024 Bit der Nachricht ab. Bezogen auf unterschiedliche Anwendungen lässt das folgende Schlüsse zu:

a) normale Texte: was vorher normales ASCII-Geschehen war, ist nach Erzeugen einer Kollision binäres Durcheinander. Das sollte eigentlich auffallen.

b) Formatierte Texte (Word, usw.): hier bestünde die Möglichkeit, im oft vorhandenen Datenüberhang (nicht von Nutzdaten beaufschlagter Dateibereich) einen Block gegen einen Kollisionsblock auszutauschen. Allerdings sind das nur 1024 Bit an nicht dargestellter Information, von denen <=512 nutzbar wären. Theoretisch ergibt sich daraus allenfalls die Möglichkeit, geheime Informationen in signierten Dokumenten in kleinen Paketen zu exportieren.

c) Programme: in einem signierten selbstauspackenden Programm könnte eine Weiche gestellt werden. Beispiel: Shareware-Programm mit der Aufforderung "zahle 20 Euro an Hersteller" und "zahle 50 Euro an Cracker". Normalerweise wird Meldung 1 gedruckt. Der Cracker (= Hersteller des Packerprogramms) lädt die Shareware herunter, tauscht den Kollisionsblock aus und bietet den Download auf seiner Seite an. Nun wird Meldung 2 ausgedruckt. Der Cracker gewinnt 30 Euro (20 zahlt er an den Sharewarehersteller für die Lizenznummer, die er weitergibt).

d) Zertifikate: da hier Binärkode drinsteht, kann unerkannt ein Kollisionsblock ausgetauscht werden. Allerdings: Bei RSA-Parametern kann der öffentliche Schlüssel ausgetauscht werden, was aber nichts nützt, da der dazu passende Geheimschlüssel vom Cracker nicht erzeugt werden kann, oder das Modul, was aber voraussichtlich auch wenig nützt, da die Faktorisierung für einen weiteren Betrug bekannt sein muss, die Kollision aber in weiten Teilen Zufallscharakter aufweist, was dem entgegensteht. Bei gleichzeitigem Austausch von Modul und Schlüssel wird mit hoher Wahrscheinlichkeit die ASN.1-Struktur beschädigt, der komplette Datensatz also ungültig. Bei DH-Parametern läuft ein Austausch auf das Problem hinaus, den diskreten Logarithmus lösen zu müssen, was dem Cracker auch nicht gelingt. Aller Voraussicht nach kann ein Angriff auf Zertifikate nur DoS (Denial of Service) zur Folge haben, nicht aber ein gefälschtes nutzbares Zertifikat (d.h. eine Signatur kann nicht verifiziert werden, eine verschlüsselte Nachricht kann nicht entschlüsselt werden, der Cracker gelangt aber nicht in Besitz vertraulicher Informationen oder kann Sigaturen fälschen).

e) MAC (Message Authentication Code): nicht nutzbar, da Geheimschlüssel unbekannt.

Weitere Hinweise auf meiner Seite

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?

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.

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

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 :-() :-)

Pseudocode

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)

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)

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)

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

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

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)

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)

integritaet vs. schutz vor veraenderung

zur begruendung meines reverts: wenn auf einem FTP-server zu einer datei noch eine datei mit dem MD5-hashwert liegt, dann kann man mit dem pruefen des MD5-wertes uebertragungsfehler verhindern, nicht aber boeswilliges veraendern der datei. grund: ein angreifer kann zu seiner veraenderten datei den MD5-wert berechnen und diesen auf dem server ablegen. damit wird die ueberpruefung stimmen. gegen einen solchen angriff benoetigt man also eine Digitale Signatur (oder man muss den MD5-wert aus einer vertrauenswuerdigen quelle beziehen). --Mario d 21:23, 17. Aug. 2011 (CEST)

Die Figure ist falsch

In der Figure wird jeweils der Nachrichtenteil M_i verwendet. Nach dem Pseudocode und RFC müsste es jedoch M_g sein, wobei g je nach Runde entweder i, (5i + 1) mod 16, (3i + 5) mod 16 oder (7i) mod 16 ist. Ich habe leider nicht die Originalgrafik gemacht, sonst würde ich es ändern. --213.135.238.211 15:47, 8. Feb. 2013 (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)

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))