Diskussion:Message-Digest Algorithm 5

Automatische Archivierung

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

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind.

Zum Archiv

Wie wird ein Archiv angelegt?

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

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)

Ist jetzt im Text eingearbeitet. --Matthäus Wander 14:17, 4. Feb. 2023 (CET)

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)

Hash Sicherheit unwichtig

Diesen Beitrag konzentriert unverhältnismässig stark auf Sicherheit. Einsatzbereiche MD5 sind aber sehr gut andere. Zum Beispiel das erstellen von Hash codes. MD5 ist schnell und wenig rechenintensiv aber durchaus von Kollisionen geplagt. Das heisst aber nicht das es nicht prima eingesetzt werden kann als einfache, praktische und platzsparende Speicherung von hash codes. Diese Objektivität fehlt mir. Theking2 (Diskussion) 21:23, 30. Mär. 2024 (CET)

MD5 wurde als kryptographisch sichere Hashfunktion entworfen und war als solche zeitweise weltweiter Rangführer. Die nunmehr nachgewiesene Unsicherheit ist hochgradig relevant und führte zu umfangreichen Bemühungen, von MD5 zu anderen Hashfunktionen zu migrieren. Dies umfänglich zu beschreiben ist kein Mangel an Verhältnismäßigkeit oder Objektivität.

Im nichtkryptographischen Bereich konkurriert MD5 mit für diesen Anwendungszweck entworfenen Hashfunktionen, beispielsweise FNV (Informatik), und schneidet mittelmäßig ab [1]. --Matthäus Wander 00:43, 1. Apr. 2024 (CEST)

Verwendung: Datenbanken

Spezial:Diff/237689335/243591987: Ich vermisse in dem Beispiel eine Erläuterung, welchen Mehrwert MD5 liefert. Geht es darum, einen schnellen URL-Abruf über den Index `ix_code_hash` zu ermöglichen? Das Code-Beispiel ist ohne Erläuterung nicht hilfreich. --Matthäus Wander 01:02, 1. Apr. 2024 (CEST)

Änderungsvorschlag: Spezial:Diff/243965312 --Matthäus Wander 20:06, 11. Apr. 2024 (CEST)