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

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)

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)

Wozu brauchen wir kollisionsresistente Hashfunktionen?

Die Schnorr-Signatur fordert keine Kollisionsresistenz. Wir können also eine sichere Digitale Signatur auch mit MD5 verwirklichen. Wozu also?

Aber wir können auch aus zwei MD5-Werten einen Hashwert mit 256-Bits konstruieren, eine kollisionsresistente Hashfunktion.

1. Berechne h1 := MD5(m)
2. Berechne h2 := MD5( h1 || m )
3. h_res := h1 || h2

Dabei steht || für das Aneinanderhängen der beiden Bitstrings.

Begündung: Ist h1 ebenso wie h2 eine Zufallsorakel ist auch h_res ein Zufallsorakel mit doppelter Länge. --Franz Scheerer aus Wiesbaden (Diskussion) 21:30, 17. Jan. 2023 (CET)

Jetzt erklärt mir einmal wie ihr davon Kollisionen finden wollt. --Franz Scheerer aus Wiesbaden (Diskussion) 21:33, 17. Jan. 2023 (CET)

1. Das ist schön, dass die Schnorr-Signatur keine Kollisionsresistenz benötigt. Es gibt aber andere Anwendungszwecke, die Kollisionsresistenz voraussetzen, z. B. DSA.
2. Die Aussage, dass MD5 mit Schnorr-Signaturen sicher sei, ist eine Wertung (POV), die ziemlich gewagt ist. Dass die Kollisionsresistenz von MD5 innerhalb von Sekunden gebrochen werden kann, ist ein Beleg, dass MD5 nicht die behaupteten Sicherheitseigenschaften erfüllt. Der Konsens unter Kryptologen ist: das Risiko für weitere Sicherheitsprobleme, beispielsweise bzgl. Preimage-Resistenz, ist zu hoch und daher wird von einer weiteren Verwendung von MD5 abgeraten. Tatsächlich gibt es auch theoretische Angriffe auf die Preimage-Resistenz [1]. Zwar ist der Angriff mit 2^123 Operationen jenseits der Praktikabilität, aber auch hier gilt: die Sicherheitseigenschaft ist formal gebrochen und das Risiko für weitere Angriffe, die praktisch relevant sein könnten, ist zu hoch.
3. Überdenk bitte, ob Anspruchshaltung ("Jetzt erklärt mir einmal wie ihr ...") der richtige Ton für die Diskussion ist. --Matthäus Wander 15:11, 19. Jan. 2023 (CET)

   Dann erkläre es uns doch.

   Ist h1 ein Zufallsorakel, ist der Hashwert echter Zufall, sofern der Wert noch nicht berechnet wurde, sonst wird der zuvor, bei der ersten Berechnung bestimmte Zufallswert zurückgegeben. Wenn auch h2 ein solches Zufallsorakel ist, dann gilt dies offensichtlich auch für den zusammengesetzten Wert h_res. Wäre MD5 ein iedeales Zufallsorakel hätten wir so ein ideales Zufallsorakel mit 256 Bits Output gewonnen. Jetzt ist MD5 natürlich kein 100 Prozent ideales Zufallsorakel mit 128 Bits. Ich denke aber, so weit ist MD5 davon gar nicht entfernt. Ich kenne jedenfalls keine eindeutig bessere Hashfunktion mit 128 Bits. Daher vermute ich unser so konstruiertes h_res besitzt Kollisionsresistenz. Wer es nicht glaubt, sollte erklären wie Kollisionen gefunden werden könnten oder am besten solche berechnen. --178.202.60.40 11:05, 24. Jan. 2023 (CET)

   Es gibt noch weitere Möglichkeiten solche Varianten von MD5 zu konstruieren. Wir könnten zum Beispiel die Nachricht mit einem möglichst simplen und schnellen Algorithmus wie RC4 verschlüsseln, Als Schlüssel könnten wir den Wert h1 verwenden. Die Variante h2 berechnen wir dann mit MD5 aus der verschlüsselten Nachricht. Wir könnten natürlich auch die 64 Konstanten K in MD5 anders berechnen. --Franz Scheerer aus Wiesbaden (Diskussion) 11:15, 24. Jan. 2023 (CET)

   Wir könnten auch zweimal verschlüsseln, die Chiffre nochmals verschlüsseln und aus beiden Chiffren einen MD5-Hash berechnen. Ingesamt hätten wir einen neuen Hash mit 256 Bits. Idealerweise verwendet die Chiffre eine Form des Cipher Feedback Mode. Ich bin ziemlich sicher, ein solcher 256-Bit-Wert wäre kollisionsresistent. --Franz Scheerer aus Wiesbaden (Diskussion) 11:53, 21. Mär. 2023 (CET)

   Ich üblege gerade, wenn zuerst verschlüsseln, so dass sich die Bits lawinenartig, zufällig über die gesamte Nachricht verteilen, erreichen wir dann eine kollisionsresistene Hashfunktion mit einem MD5-Hash?

   Die Antwort ist NEIN. Mit der Pollard-Rho-Methode können bei nur 128 Bits immer Kollisionen gefunden werden.

   Hmmmmm - schade. --Franz Scheerer aus Wiesbaden (Diskussion) 15:08, 21. Mär. 2023 (CET)

Persönliche Betrachtungen gehören nicht auf die Diskussionsseite.—Ilse Ongkim (Diskussion) 13:02, 2. Apr. 2023 (CEST)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 13:02, 2. Apr. 2023 (CEST)

Konstanten mit Python berechnet

import math

for i in range(64):

  if i < 63:

    print ("0x{:x},".format(math.floor(abs(math.sin(i+1) * 2**32))))

  else:

    print ("0x{:x}".format(math.floor(abs(math.sin(i+1) * 2**32))))

0xd76aa478,

0xe8c7b756,

0x242070db,

0xc1bdceee,

0xf57c0faf,

0x4787c62a,

0xa8304613,

0xfd469501,

0x698098d8,

0x8b44f7af,

0xffff5bb1,

0x895cd7be,

0x6b901122,

0xfd987193,

0xa679438e,

0x49b40821,

0xf61e2562,

0xc040b340,

0x265e5a51,

0xe9b6c7aa,

0xd62f105d,

0x2441453,

0xd8a1e681,

0xe7d3fbc8,

0x21e1cde6,

0xc33707d6,

0xf4d50d87,

0x455a14ed,

0xa9e3e905,

0xfcefa3f8,

0x676f02d9,

0x8d2a4c8a,

0xfffa3942,

0x8771f681,

0x6d9d6122,

0xfde5380c,

0xa4beea44,

0x4bdecfa9,

0xf6bb4b60,

0xbebfbc70,

0x289b7ec6,

0xeaa127fa,

0xd4ef3085,

0x4881d05,

0xd9d4d039,

0xe6db99e5,

0x1fa27cf8,

0xc4ac5665,

0xf4292244,

0x432aff97,

0xab9423a7,

0xfc93a039,

0x655b59c3,

0x8f0ccc92,

0xffeff47d,

0x85845dd1,

0x6fa87e4f,

0xfe2ce6e0,

0xa3014314,

0x4e0811a1,

0xf7537e82,

0xbd3af235,

0x2ad7d2bb,

0xeb86d391 --Franz Scheerer aus Wiesbaden (Diskussion) 11:47, 20. Jan. 2023 (CET)

Es scheint mit den Angaben im Artikel übereinzustimmen.

So jetzt könnten wir sin durch cos, Die Sinusfunktion durch die Cosinusfunktion ersetzen. Warum nicht, ist doch Jacke wie Hose. --Franz Scheerer aus Wiesbaden (Diskussion) 11:52, 20. Jan. 2023 (CET)

Damit hätten wir zwei Hashfunktionen. Jetzt könnten wir die beiden 128-Bitwerte zu einem 256-Bitwert zusammenfassen. Schon hätten wir Kollisionsresistenz. --Franz Scheerer aus Wiesbaden (Diskussion) 11:55, 20. Jan. 2023 (CET)

Beachte: An den Stellen x=(i+1) mit i=0,1,2, ..., 63 sind sin(x) und cos(x) irrationale Zahlen (ungleich 0) größer minus 1 und kleiner 1. Durch Multiplikation mit 2 hoch 32 und Rundung auf ganze Zahlen erhalten wir pseudozufällige 32-Bitwerte. Analog könnten wir auch 64-Bitwerte erhalten, durch Multiplikation mit 2 hoch 64. --Franz Scheerer aus Wiesbaden (Diskussion) 21:10, 26. Jan. 2023 (CET)

Jetzt mit der Cosiunusfunktion:

import math

print ('{')

out = ''

for i in range(64):

  if i < 63:

    out += ("0x{:x},".format(math.floor(abs(math.cos(i+1) * 2**32))))

  else:

    out += ("0x{:x}".format(math.floor(abs(math.cos(i+1) * 2**32))))

  if i % 4 == 3:

    print(out)

    out = ''

print('}')

{

0x8a51407d,0x6a88995d,0xfd7025f4,0xa7553036,

0x489e15c1,0xf5cdb84b,0xc0ffbcf6,0x253f7d7e,

0xe93fd535,0xd6cd6448,0x1220ae4,0xd806d023,

0xe84e6ea9,0x230135d8,0xc27ae834,0xf5292bf4,

0x46711ac1,0xa90a840a,0xfd1bbef0,0x687810e5,

0x8c37fc1b,0xfffd6ec6,0x8867beac,0x6c96fed4,

0xfdbf77ac,0xa59c8134,0x4ac99be5,0xf66d568a,

0xbf80b2c1,0x277d05e4,0xea2c8e1f,0xd58fa982,

0x3661adb,0xd93be6ca,0xe7585f52,0x20c23a76,

0xc3f22ce1,0xf47fb4d2,0x4442b612,0xaabc73eb,

0xfcc24453,0x66657006,0x8e1be7c3,0xfff5bb27,

0x867b8079,0x6ea336bb,0xfe09b282,0xa3e07fda,

0x4cf3a208,0xf708037e,0xbdfdd143,0x29b9c389,

0xeb1494a7,0xd44da632,0x5aa195e,0xda6ca20a,

0xe65dac20,0x1e8296e0,0xc5658374,0xf3d1564b,

0x4212f2e5,0xac6af723,0xfc63b7e7,0x6450c165

} --178.202.60.40 09:09, 21. Jan. 2023 (CET)

Was hat das mit dem Artikel Message-Digest Algorithm 5 zu tun? --Matthäus Wander 12:47, 24. Jan. 2023 (CET)

Der Artikel enthält die exakte Beschreibung des Algorithmus als Pseudocode. Dieser Pseudocode enthält eine Reihe von Konstanten, mit K[ ...] bezeichnet, die mittels der Sinusfunktion berechnet pseudozufällig berechnet werden können. Die Sinusfunktion kann ohne Weiteres durch die Cosinusfunktion ersetzt werden. Wenn wir im MD5-Algorithmus die mittels Sinunsfunktion berechneten Konstanten durch aus der Cosinusfunktion berechnete Konstanten ersetzen, erhalten wir eine zu MD5 völlig gleichwertige Hashfunktion. Beide Varianten erlauben es 256 Pseudozufallsbits aus einer beliebigen Nachricht zu berechnen. Damit erhalten wir eine kollisionsresistene Hashfunktion. --Franz Scheerer aus Wiesbaden (Diskussion) 12:47, 25. Jan. 2023 (CET)

Danke für die Erläuterung. Dabei handelt es sich um Theoriefindung. --Matthäus Wander 13:10, 25. Jan. 2023 (CET)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 13:02, 2. Apr. 2023 (CEST)

64-Bit-Variante?

MD5 ist für die 32-Bit-Architektur entwickelt. Der Output ist in 4 "Worte" A-D mit je 32 Bits unterteilt. Wenn wir jetzt alle 32 Bit-Blöcke in 64-Bit-Blöcke umwandeln. Wir bekämem dann einen 4*64 = 256 Output und somit eine kollisionsresistente Hashfunktion. Moderne Rechner mit 64-Bit-Architektur wären praktisch genauso schnell. Warum wird das eigentlich nicht gemacht? --Franz Scheerer aus Wiesbaden (Diskussion) 10:20, 26. Jan. 2023 (CET)

Es gibt schon länger den Nachfolger SHA-2 mit Varianten, die 512 Bit lange Hashwerte berechnen (8 Wörter mit je 64 Bit) und davon je nach Variante 224, 256, 384 oder 512 bit ausgeben. MD5 ist veraltet; wenn du eine wirklich gute Hashfunktion ohne bekannte Schwächen suchst, empfehle ich SHA-512/256. --Megatherium (Diskussion) 11:39, 26. Jan. 2023 (CET)

Richtig -wie bei SHA-2 (SHA-256 -> SHA-512) könnten auch bei MD5 aus den 32-Bit-Blöcken einfach 64-Bit-Blöcke gemacht werden. Dann hätten wir bereits eine kollisionsresistente Hashfunktion, die noch deutlich schneller als SHA-512 ist. Nur 512 Bits Output braucht kein Mensch. --178.202.60.40 15:30, 26. Jan. 2023 (CET)

Obwohl, wenn wir diese 512 Zufallsbits zum Beispiel zum Verschlüsseln verwenden, dann ist es schon von Vorteil. Auf einem modernen 64-Bit-Rechner ist SHA-512 sehr schnell. --Franz Scheerer aus Wiesbaden (Diskussion) 15:41, 26. Jan. 2023 (CET)

Wir können die überflüssigen 256-Bits von SHA-512 auch einfach ignorieren, abschneiden, weglassen. Ich habe gerade in SHA-2 gelesen, dass dies sogar vom BSI akzeptiert, als standardkonform empfohlen wird. Da heute fast alle Rechner die 64-Bit-Architektur verwenden, erscheint es mir widersinnig noch SHA-256 basierend auf der 32-Bit-Architektur zu verwenden. Das Weglassen von 256 Bits hat auch einen Vorteil. Aus dem Hashwert einer Nachricht kann dann in keinem Fall der Hashwert einer verlängerten Nachricht berechnet werden. Die Nachricht könnte mit einem geheimen Schlüssel beginnen. Damit erhalten wir in einfacher Weise einen Message Authentication Code. Diesen könnten wir auch noch weiter verkürzen, mehr als 128 Bits ergeben keinen Sinn. --178.202.60.40 09:58, 27. Jan. 2023 (CET)

Es ist zumindest eine Tatsache, dass für sämtlich SHA-2-Varianten keine Kollisionen bekannt sind. --Franz Scheerer aus Wiesbaden (Diskussion) 21:29, 26. Jan. 2023 (CET)

Mit Python3 in Knoppix können wir auch SHA-3 verwenden:

>>> print(hashlib.sha3_256('Test'.encode()).hexdigest())

c0a5cca43b8aa79eb50e3464bc839dd6fd414fae0ddf928ca23dcebf8a8b8dd0 --Franz Scheerer aus Wiesbaden (Diskussion) 10:23, 27. Jan. 2023 (CET)

Ich habe es mit einer Online-Implementierung probiert. Die kennt auch schon sha3_256. Dieser neue Standard ist offenbar mit der Programmiersprache Python praktisch überall auch online verfügbar. Vielleicht ist es Zeit auf den neuen Standard umzusteigen. SHA-3 ist wirklich bombensicher und dabei noch sehr schnell.. --Franz Scheerer aus Wiesbaden (Diskussion) 17:49, 7. Feb. 2023 (CET)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 13:03, 2. Apr. 2023 (CEST)

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)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 13:04, 2. Apr. 2023 (CEST)

Python zur Verschlüsselung mit MD5

Die Hashwerte werden aus folgenden 'Nachrichten' berechnet:

password password# password## password### password#### ...

Daraus ergibt sich ein fast perfektes One-Time-Pad, wenn das Passwort nur einmal verwendet wird. Aus jeder 'Nachricht' werden 128 Bits oder 16 Bytes berechnet. --Franz Scheerer aus Wiesbaden (Diskussion) 21:14, 18. Mär. 2023 (CET)

import sys, hashlib

if len(sys.argv) > 1:

  pw = sys.argv[1]

  f = open('in','rb')

  x = list(f.read())

  f.close()

  cnt = 0

  md = hashlib.md5(pw.encode())

  ix = 0

  while cnt < len(x):

     if ix == 0:

        bs = md.digest()

        md.update('#'.encode())    

     x[cnt] = x[cnt] ^ bs[ix]

     cnt = cnt + 1

     ix = (ix + 1) % 16

  f=open('out','wb')

  f.write(bytes(x))

  f.close()

else:

  print("Das Passwort wurde nicht angegeben") --Franz Scheerer aus Wiesbaden (Diskussion) 18:54, 11. Mär. 2023 (CET)

Die einfachste Lösung ist die Beste. Das Skript ist bereits perfekt, wenn das Passwort nicht wiederverwendet wird (etwa mit MD5 aus der Nachricht errechnet) und nicht erraten werden kann-

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 13:04, 2. Apr. 2023 (CEST)

Das Skript zum Entschlüsseln (MD5-Crypt)

https://onlinegdb.com/lRo33fvEt --Franz Scheerer aus Wiesbaden (Diskussion) 19:58, 15. Mär. 2023 (CET)

Wikipedia ist eine Enzyklopädie, die bekanntes Wissen abbildet. Die Verbreitung von selbst entwickelten Skripten ist hier fehl am Platze. Siehe bitte WP:WWNI, speziell Punkt 2 und 9. --Matthäus Wander 09:20, 17. Mär. 2023 (CET)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 13:04, 2. Apr. 2023 (CEST)

Noch einmal - Verschlüsselung mit MD5

https://onlinegdb.com/7B08mWnLC

Noch einfacher und praktisch, die Sysytemzeit wird der Datei vorangestellt. Dann genügt ein Durchlauf. --Franz Scheerer aus Wiesbaden (Diskussion) 18:59, 16. Mär. 2023 (CET)

Das Passwort kann wiederverwendet werden, weil die vorangestellte Zeit sich nicht wiederholt. --Franz Scheerer aus Wiesbaden (Diskussion) 19:03, 16. Mär. 2023 (CET)

In dieser oder ähnlicher Weise kann eine Verschlüsselung mit wiederverwendbarem Passwort mit relativ geringem Aufwand erstellt werden. Das Verfahren ist so sicher wie es unmöglich ist, das Passwort zu erraten. Besser geht nicht, Standard-Verfahren zur Verschlüsselung sind vollkommen unnötig. --Franz Scheerer aus Wiesbaden (Diskussion) 11:02, 17. Mär. 2023 (CET)

Dieser Abschnitt kann archiviert werden. 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)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 13:04, 2. Apr. 2023 (CEST)

Genau so ist es - MD5 ist praktisch schon perfekt!

Eine Nachricht zu gegebenen MD5-Hashwert kann praktisch nicht gefunden werden. In drei Jahrzehnten ist es niemand gelungen. Es wird auch in Zukunft niemand gelingen. Als MD5 entworfen wurde waren Computer noch um Größenordnungen langsamer als heute. MD5 ist also gewiss auch schnell genug. Wir können noch einen SALT verwenden. Damit haben wir praktisch eine neue Hashfunktion kreiert, so dass Regenbogentabellen nicht verwendet werden können. Punkt aus, da gibt es nichts mehr zu verbessern. Wir brauchen das Rad nicht erneut erfinden.

md5("Franz jagt im komplett verwahrlosten Taxi quer durch Bayern") =
a3cca2b2aa1e3b5b3b5aad99a8529074

Eine kleine Änderung des Textes erzeugt aufgrund des Lawineneffekts einen komplett anderen Hashwert. Eine weitere Nachricht mit dem MD5-Hashwert a3cca2b2aa1e3b5b3b5aad99a8529074 kann praktisch nicht bestimmt werden. Beispielsweise ergibt sich mit Frank statt Franz (nur ein Buchstabe verändert):

md5("Frank jagt im komplett verwahrlosten Taxi quer durch Bayern") =
7e716d0e702df0505fc72e2b89467910

--Franz Scheerer aus Wiesbaden (Diskussion) 10:14, 23. Mär. 2023 (CET)

... und Kollisionsresistenz brauchen wir nicht wirklich, siehe Schnorr-Signatur. --Franz Scheerer aus Wiesbaden (Diskussion) 10:16, 23. Mär. 2023 (CET)

Derartige Meinungsäußerungen sind in einem persönlichen Blog besser aufgehoben als auf den Diskussionsseiten der Wikipedia. Bitte WP:DISK beachten. --Matthäus Wander 11:34, 23. Mär. 2023 (CET)

Das soll auch nicht alles in den Artikel aufgenommen werden. Das Wichtige, die wesentlichen Fakten stehen bereits im Artikel. --Franz Scheerer aus Wiesbaden (Diskussion) 12:17, 23. Mär. 2023 (CET)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 12:57, 2. Apr. 2023 (CEST)

Der entscheidende Punkt

Ein erfolgreicher Preimage-Angriff ist auch nach mehr als drei Jahrzehnten nicht bekannt. Dies ist wirklich bemerkenswert, denn kaum eine Kryptographische Hashfunktion wurde intensiver analysiert.

128 Bits sind nicht ausreichend für Kollisionsresistenz. Doch dies ist für viele Anwendungen gar nicht erforderlich. --Franz Scheerer aus Wiesbaden (Diskussion) 12:47, 2. Apr. 2023 (CEST)

Offensichtlich sind die vielen Kollisionen, die inzwischen gefunden wurden, nicht hilfreich für Preimage-Angriffe. --Franz Scheerer aus Wiesbaden (Diskussion) 12:49, 2. Apr. 2023 (CEST)

Sorry, aber diese Seite dient der Diskussion über den Artikel, nicht Meinungsäußerungen zum Algorithmus.—Ilse Ongkim (Diskussion) 12:57, 2. Apr. 2023 (CEST)

Dieser Abschnitt kann archiviert werden. Ilse Ongkim (Diskussion) 12:57, 2. Apr. 2023 (CEST)