Hashes
-
Hi, zwei kleine Fragen:
1. Warum werden MD5 und SHA-0/1 als "broken" angesehen, SHA256/512 aber nicht? Mich interessiert hier der Knackpunkt an dem gemessen entschieden ist, wann ein Hash Algorithmus als "broken" gesehen wird, keine vollständige Kryptoanalyse.
2. Gibt es für asymmetrische Verschlüsselungen auch so einen quasi Standard, wie es für symmetrische Verfahren AES ist? (RSA vielleicht?)
Danke schon mal jetzt.
-
interessierter schrieb:
Hi, zwei kleine Fragen:
1. Warum werden MD5 und SHA-0/1 als "broken" angesehen, SHA256/512 aber nicht? Mich interessiert hier der Knackpunkt an dem gemessen entschieden ist, wann ein Hash Algorithmus als "broken" gesehen wird, keine vollständige Kryptoanalyse.
2. Gibt es für asymmetrische Verschlüsselungen auch so einen quasi Standard, wie es für symmetrische Verfahren AES ist? (RSA vielleicht?)
Danke schon mal jetzt.
auch wenn es diesem komplexen thema nicht unbedingt gerecht wird, geht es meist einfach um schlüssellängen.
@edit: bei hash gibt es dann noch die möglichkeit, dass man kollisionen erzeugen kann, was dann je nach aufwand und einsatzgebiet den hash wertlos macht.
btw. hash is sowieso kacke... schmeckt zum kotzen
-
_-- schrieb:
btw. hash is sowieso kacke... schmeckt zum kotzen
Ist ja auch nicht als Nahrungsmittel gedacht.
-
_-- schrieb:
btw. hash is sowieso kacke... schmeckt zum kotzen
Kann ich dir nur recht geben.
Hat schon bei meinem Grenzübertritt von Marokko nach Spanien (vor vielen Jahren) einfach nur kacke geschmeckt,
-
interessierter schrieb:
1. Warum werden MD5 und SHA-0/1 als "broken" angesehen, SHA256/512 aber nicht? Mich interessiert hier der Knackpunkt an dem gemessen entschieden ist, wann ein Hash Algorithmus als "broken" gesehen wird, keine vollständige Kryptoanalyse.
Also ich hoffe dass ich es richtig verstanden habe, und halbwegs richtig wiedergeben kann. Falls das Teilweise Unsinn und/oder unklar ist bitte berichtigen.
"broken" heisst dass Möglichkeiten ("Angriffe") gefunden wurden mit praktikablem Aufwand Kollisionen zu erzeugen. Wobei praktikabler Aufwand bedeutet dass die Chance besteht das mit optimistisch geschätzter Entwicklung der Technik und grossem finanziellen Aufwand in absehbarer Zeit durchführen zu können. Ganz besonders schlimm natürlich wenn es mit heutiger Technik und einem einzigen dicken PC machbar ist.
Und es gibt mehrere Fälle bzw. Kategorien von Angriffen zu unterscheiden. Dementsprechend mehr oder weniger "broken" kann ein Algorithmus sein.
Nennen wir die beiden zu hashenden Datensätze (Files, Strings - Byte-Würste halt) mal A und B. Eine Kollision ist dann wenn hash(A) == hash(B).
Nicht sehr schlimm ist, wenn der Angrif der die Kollisionen erzeugt A und B vollständig vorgibt. Also andersrum: keinerlei Einschränkungen bezüglich A und keinerlei Einschränkungen bezüglich B erlaubt. Man kann dann zwar hübsch massenweise Kollisionen erzeugen, aber man kann mit den Paaren (A,
die dabei rauskommen in den meisten Fällen nix anfangen. Sind halt irgendwelche Datenwürste die den gleichen Hashcode haben. Vermutlich gibt es einige Anwendungen wo sogar das schon schlimm wäre, aber bei den Sachen die mir jetzt einfallen könnte man damit maximal ein wenig Verwirrung stiften.Schlimm ist dagegen, wenn ich ein A so "vorbereiten" kann, dass ich mit dem "vorbereiteten" A (nennen wir es A') einfach eine Kollision erzeugen kann.
Wobei "vorbereiteten" jetzt heisst ich modifiziere Teile von A auf eine ganz bestimmte Art & Weise.
z.B. ich füge in einem File einen Padding-Block/Kommentar-Block/... ein der mit vom Angriff vorgegebenen Daten angefüllt werden kann.
Wenn ich mir dann noch aussuchen kann welche Änderung ich in B' haben möchte ist die Kacke am dampfen.Angenommen ich habe ein File-Format das eben solche Padding-Blöcke erlaubt - wozu auch immer. Möglicherweise um das dauernde Umkopieren von Daten zu vermeiden wenn nur kleine Änderungen gemacht werden. Wenn ich mich richtig erinnere erlaubt ID3v2 (z.B. in einem MP3 File) sowas.
Dann kann ich ein File A so abändern dass ich ein A' erhalte das vollkommen "normal" aussieht, ein 100% gültiges Exemplar seines File-Formats ist, und gleichzeitig an einer passenden Stelle die vom Angriff vorgegebenen Daten enthält.
Dieses A' lasst ich mir dann von irgendwem signieren.
Und dann lasse ich mir ein B' mit ein paar gewünschten Änderungen erzeugen (bzw. u.U. sogar komplett anderem Inhalt), wobei der Angriff dann z.B. die Daten im Padding-Block beliebig abändern kann um die Kollision zu erzeugen.
Und schwupps: B' die für A' erzeugte Signatur gilt ebenso für B'. Böse Sache.Etwas allgemeiner formuliert: sobald man Bedingungen für Teile von A und B vorgeben kann, kann man damit vermutlich böse Dinge anstellen.
Und katastrophal ist es, wenn man A komplett vorgeben kann, und Teile der gewünschten Änderung in B. Dann muss man die Schummelei nämlich nichtmal vorbereiten.
War es das was du wissen wolltest?
2. Gibt es für asymmetrische Verschlüsselungen auch so einen quasi Standard, wie es für symmetrische Verfahren AES ist? (RSA vielleicht?)
Ich kenne zwei Verfahren die sich beide grosser Beliebtheit erfreuen, und beide quasi-standard sind: RSA und ECC (Elliptic Curve Cryptography).
Beide werden z.B. ausgiebigst für Zertifikate eingesetzt.
Ich würde aber nicht behaupten dass eines davon "mehr standard" ist als das andere.Mein klarer Favorit ist ECC. Wobei ich auch den Eindruck habe dass allgemein die Tendenz zu ECC geht. Weil man die gleiche Sicherheit mit wesentlich kürzeren Schlüsseln bekommt.
-
-
hab ich jetzt das forum kaputt gemacht
-
_-- schrieb:
hab ich jetzt das forum kaputt gemacht
Ja. Mach sofort den Thread wieder heile!
-
cooky451 schrieb:
_-- schrieb:
hab ich jetzt das forum kaputt gemacht
Ja. Mach sofort den Thread wieder heile!
-
@hustbaer
Wenn ich mir das so durchlese, bedeutet das doch, dass das Speichern von Passwörtern als gesalzene MD5 Hashes immernoch sicher ist? (Also man kann die Passwörter nicht mehr in Klartext herstellen oder einen Klartext finden, der den gleichen Hash erzeugt.)
-
cooky451 schrieb:
@hustbaer
Wenn ich mir das so durchlese, bedeutet das doch, dass das Speichern von Passwörtern als gesalzene MD5 Hashes immernoch sicher ist? (Also man kann die Passwörter nicht mehr in Klartext herstellen oder einen Klartext finden, der den gleichen Hash erzeugt.)Korrekt.
Trotzdem ist md5 für Passwörter blöd. Weil MD5 ist zu schnell. Man will für Passwörter einen langsamen Hash Alogorithmus haben.
Aber solange gut gesalzen ist, ists sicher genug.
Die Sicherheit eines Hash Algos hat damit aber nichts zu tun. Die Sicherheit sagt aus wie schwer es ist Kollisionen generieren zu können. Schwache Hashes erleichtern es nicht an den Klartext zu kommen, sie erleichtern nur Kollisionen (was oft reicht, aber zB bei knacken einer geklauten DB mit Passwörtern wäre es egal).
-
Shade Of Mine schrieb:
Trotzdem ist md5 für Passwörter blöd. Weil MD5 ist zu schnell. Man will für Passwörter einen langsamen Hash Alogorithmus haben.
Aber solange gut gesalzen ist, ists sicher genug.
Zu 99% würde ich Dir zustimmen, sehe aber die Geschwindigkeit nicht als Nachteil.
Bei einem schnellen Algorithmus hat der Entwickler die Freiheit, einfach mal 829 Zyklen zu durchlaufen und kann trotzdem einen bewährten und auf allen Plattformen verfügbaren Algorithmus einsetzen.Wie sicher es sein muss, hängt im wesentlichen vom Angriffsszenario ab. Ein Angriff auf ein spezielles Kennwort (wie das eines Foren-Admins) ist wesentlich aufwendiger als das Ziel, irgendeines der vielen Konten zu hacken (um z.B. ein ebay-Konto zu kapern).
Das Salzen braucht dann gar nicht mal über individuelle Zufallszahlen laufen, ggf. reicht schon die Einbeziehung des Klartextes und/oder die Anzahl der Zyklen.Ciao, Allesquatsch
-
Salzen verhindert nur Angriffe über Rainbow-Tables, und macht das berechnen des Hashcodes minimal langsamer.
Gerade aber bei gezielten Angriffen auf ein einzelnes Passwort ist es wichtig dass der "Test" möglichst lange dauert.
Das Salz steht dir dabei ja zur Verfügung, bringt also nix bezüglich Sicherheit. Ausschlaggebend ist dann nur die Entropie des Passworts * Aufwand für 1x Probieren.
-
hustbaer schrieb:
Salzen verhindert nur Angriffe über Rainbow-Tables, und macht das berechnen des Hashcodes minimal langsamer.
Klares JEIN
JA, Salz ist das einfachste Mittel, um Angriffe auf entwendete Zugangsdaten über Rainbow-Tables abzuwehren.
NEIN, Salz ich jenseits der Rainbow-Tables hilfreich. Denn neben Rainbow-Tables sind Wörterbuchattacken ein erfolgreiches Rezept, um in geklauten Kennwort-Tabellen Treffer zu erzielen.
In schlechten Implementierungen wurde häufig nur das Kennwort als Klartext durch den MD5 gejagt. Und wegen des Hashs wird sowas auch nicht später geändert, um keine Benutzer zu verlieren.
Entsprechend sind die Hashes auch bei allen Benutzern gleich, die gleiche Kennworte haben.
Geht es also darum, die Identität eines von 100.000 Benutzern zu übernehmen, reicht ein Angriff für alle. Und was ohne Salz x Tage gedauert hätte, klappt jetzt in x Sekunden. Noch schneller wird es, wenn man aus den 100.000 Benutzern die vorauswählt, deren Kennworthash nicht kollisionsfrei ist.Ich gebe Dir aber Recht, dass das für echte Kryptologen keine wirklich höhere Sicherheit darstellt. In der Praxis gilt aber: Der Dieb wählt immer den leichtesten Weg - und der kann auch zum Nachbarn führen
Ciao, Allesquatsch
-
Allesquatsch schrieb:
Zu 99% würde ich Dir zustimmen, sehe aber die Geschwindigkeit nicht als Nachteil.
Bei einem schnellen Algorithmus hat der Entwickler die Freiheit, einfach mal 829 Zyklen zu durchlaufen und kann trotzdem einen bewährten und auf allen Plattformen verfügbaren Algorithmus einsetzen.Nope. Dann nimm einfach blowfish.
@hustbaer:
dass rainbow tables beim salzen nicht mehr gehen, nimmt man gerne mit.
Aber salzen verhindert, dass eine komplette DB geknackt werden kann. ein einzelner hash kann immer geknackt werden, egal welcher hash algo verwendet wird.Passwoerter sind einfach zu kurz fuer sowas.
-
Na ja. Bei den üblichen 10-14 Zeichen ist das schon ne Menge Arbeit oder nicht? Klar, schwache Passwörter mit 6 Zeichen knackt man quasi im Vorbeigehen.
-
cooky451 schrieb:
Na ja. Bei den üblichen 10-14 Zeichen ist das schon ne Menge Arbeit oder nicht? Klar, schwache Passwörter mit 6 Zeichen knackt man quasi im Vorbeigehen.
http://golubev.com/files/ighashgpu/readme.htm
Ein normaler PC den jeder bei sich zuhause haben kann, kann mehrer millionen hashes pro Sekunde berechnen. Und jetzt stell dir vor du hast eine Infrastruktur dafuer - zB ein Botnetz
-
cooky451 schrieb:
Na ja. Bei den üblichen 10-14 Zeichen ist das schon ne Menge Arbeit oder nicht? Klar, schwache Passwörter mit 6 Zeichen knackt man quasi im Vorbeigehen.
Leider dürfte das Übliche eher bei 6 als bei 10 liegen.
Mit meinem Standardkennwort für risikofreie Anwendungen bis ich auf 8 Zeichen geblieben, weil es viele Webangebote gibt, die mehr als 8 Zeichen oder Sonderzeichen ablehnen.
Auch dieses Jahr habe ich noch Webangebote gesehen, die das Kennwort im Klartext ablegen, denn es wird nachher per E-Mail verschickt.
Ciao, Allesquatsch
-
Shade Of Mine schrieb:
Ein normaler PC den jeder bei sich zuhause haben kann, kann mehrer millionen hashes pro Sekunde berechnen. Und jetzt stell dir vor du hast eine Infrastruktur dafuer - zB ein Botnetz
Unterschätze mal die Exponentialfunktion nicht.
Für 14 Zeichen haben selbst die Geheimdienste keine passende Hardware mehr. Schließlich beinhaltet Rainbow-Table einen Brute-Force.
Ciao, Allesquatsch
-
Allesquatsch schrieb:
weil es viele Webangebote gibt, die mehr als 8 Zeichen oder Sonderzeichen ablehnen.
Jo, das ist total plem.
War für mich vor 10 Jahren schon unverständlich, und ist es heute noch viel mehr. Man sollte meinen dass auch die doofen irgendwann mal dazulernen, aber dem ist wohl anscheinend nicht so.
