Entwickler-Ecke
Off Topic - Kryptographie
Dude566 - Mi 16.02.11 20:39
Titel: Kryptographie
Hallo,
ich muss demnächst in Mathematik eine Präsentation zum Thema Kryptographie halten und würde hier gerne, meinerseits aufkommende Fragen klären.
Habe mich jetzt mal auf die Schnelle ein wenig in das Thema eingelesen und auch schon einmal die Caesar-Chiffre ausprogrammiert.
Jetzt ist es ja so, das diese Verschlüsselung mit einem Computer in Millisekunden geknackt werden kann und ich auch gerne noch etwas Komplexeres zeigen möchte.
Wie läuft das denn mit diesen "Salts" ab, die sind ja nichts anderes als eine zufällig generierte Erweiterung des verschlüsselten Textes, oder?
Wie kann denn dann z.B. eine Anwendung (Forum) beim Login eines Benutzers überprüfen ob das eingegebene Passwort dem, mit einem Salt versetzen Hash, entspricht? Dieser wurde ja zufällig generiert und kann jetzt nicht noch einmal generiert werden beim Login. :gruebel:
So, das wäre mal meine erste wichtige Frage die ich hätte! ;)
Schönen Gruß,
Dude566
elundril - Mi 16.02.11 20:48
Also so wie ich das jetzt nach kurzem
einlesen [
http://www.aspheute.com/artikel/20040105.htm] verstanden habe, wird in der Datenbank im Forum der zufällig generierte Salt mitgespeichert zu jedem Benutzer. Da die Tabelle ja eh mit Passwort und so weiter geschützt ist, kann ja auch niemand den Salt auslesen. Dann wird bei jeder Passwortabfrage einfach der Salt hinten drangehängt und davon dann erst der Hashwert gebildet. Diesen Vergleicht man dann mit dem in der Datenbank gespeicherten Hash.
Wenn du auch ein bisschen was "Advanced" zeigen möchtest, dann zeig doch die
Vigenère [
http://de.wikipedia.org/wiki/Polyalphabetische_Substitution#Vigen.C3.A8re-Verschl.C3.BCsselung] Verschlüsselung her. Ist ein bisschen komplexer als die reine Cäsar-Verschlüsselung und kann auch nicht mehr so leicht anhand von Buchstabenhäufigkeiten und kurzen Wörtern entschlüsselt werden. ;)
lg elundril
Dude566 - Mi 16.02.11 20:56
 elundril hat folgendes geschrieben  : |
Also so wie ich das jetzt nach kurzem einlesen [http://www.aspheute.com/artikel/20040105.htm] verstanden habe, wird in der Datenbank im Forum der zufällig generierte Salt mitgespeichert zu jedem Benutzer. Da die Tabelle ja eh mit Passwort und so weiter geschützt ist, kann ja auch niemand den Salt auslesen. Dann wird bei jeder Passwortabfrage einfach der Salt hinten drangehängt und davon dann erst der Hashwert gebildet. Diesen Vergleicht man dann mit dem in der Datenbank gespeicherten Hash.
|
Ja, wenn das so sein sollte finde ich das aber auch ziemlich unsicher, dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken und hätte ja eigentlich keine zusätzliche Sicherheit. Denn der Salt soll das ja erschweren.
Wenn ich mich anmelde wird ja zunächst ein MD5 Hash meines Passworts und Benutzernamens generiert und dann mit den Daten aus der Datenbank abgeglichen, da bringt mir es ja nix beim erneuten Anmelden das er noch einen Salt in der Tabelle hat. Hoffe das ist verständlich wie ich das meine. :eyecrazy:
Danke, werde ich mir auch mal anschauen. ;)
Kha - Mi 16.02.11 21:23
| Dude566 hat folgendes geschrieben : |
| dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken |
Was denkst du, in wie vielen Rainbow Tables
!35§%1randomsalt3dfg4#admin123 aufgeführt ist ;) ? Als früher nur ein einziger Salt für die gesamte Website benutzt wurde, konnte für große Datenbanken wenigstens eine Rainbow Table für diesen Salt quasi On-the-Fly generiert und durchgetestet werden, aber mit Per-User-Salts hat sich das auch gegessen.
jaenicke - Mi 16.02.11 21:25
| Dude566 hat folgendes geschrieben : |
| Ja, wenn das so sein sollte finde ich das aber auch ziemlich unsicher, dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken und hätte ja eigentlich keine zusätzliche Sicherheit. |
Eben das geht dann nicht. Du hast das falsch verstanden. Der Hash wird über das Passwort plus den Salt gebildet. Das heißt in deiner Rainbowtable müsstest du die Passwörter mit dem Hash drin stehen haben.
Und das wird wie
Kha schon geschrieben hat, nicht möglich sein. ;-)
Dude566 - Mi 16.02.11 21:28
Okay, das klärt schonmal das es, wenn man Zugang zur Datenbank bekommt nicht mehr so sicher ist.
Aber was ist mit der Sache das beim Login ja auch geprüft werden muss, denn wenn ich den Salt in einem extra Feld der Tabelle mit meinen Usern nehmen würde hätte dies ja kein Sinn!
Denke mal der Salt wird dann damit gemischt, aber wie wird denn dann ein Salt der dazu passt beim Einloggen eines Benutzers generiert, dieser muss dann ja identisch zu dem hinterlegten sein, sonst könnte man ja nicht mit den Benutzerdaten in der Tabelle vergleichen.
Edit: @
jaenicke: Aber es gibt ja auch Rainbowtables die auch Salted Hashs haben, gibt halt nur nicht so viele davon.
Kha - Mi 16.02.11 21:52
| Dude566 hat folgendes geschrieben : |
| Okay, das klärt schonmal das es, wenn man Zugang zur Datenbank bekommt nicht mehr so sicher ist. |
Um das noch klarzustellen: Salts haben nur
bei einem Einbruch in die DB überhaupt einen Nutzen, also so ziemlich das Gegenteil von "nicht mehr so sicher" :) .
schwandi - Mi 16.02.11 23:51
Hab mir jetzt nicht alles durchgelesen, aber habe vor kurzem von nem Prof. die Unterlagen eines 2 tägigen Kryptografier vortrages erhalten.
Wennst mir deine Email gibst kann ich sie dir schicken, da is sicher vieles nützliches dabei ;)
lg
Dude566 - Do 17.02.11 00:07
Willst du es nicht vielleicht lieber direkt hier posten, dann hätten noch mehr Leute etwas davon die später mal auf diesen Thread stoßen. ;)
Es sei denn, das darf nicht veröffentlicht werden oder so.
BenBE - Do 17.02.11 06:13
| Dude566 hat folgendes geschrieben : |
| elundril hat folgendes geschrieben : | Also so wie ich das jetzt nach kurzem einlesen [http://www.aspheute.com/artikel/20040105.htm] verstanden habe, wird in der Datenbank im Forum der zufällig generierte Salt mitgespeichert zu jedem Benutzer. Da die Tabelle ja eh mit Passwort und so weiter geschützt ist, kann ja auch niemand den Salt auslesen. Dann wird bei jeder Passwortabfrage einfach der Salt hinten drangehängt und davon dann erst der Hashwert gebildet. Diesen Vergleicht man dann mit dem in der Datenbank gespeicherten Hash.
|
Ja, wenn das so sein sollte finde ich das aber auch ziemlich unsicher, dann könnte ich ja wenn ich den Zugang zur Datenbank geknackt bekommen würde den normalen MD5 Hash mit Rainbowtables knacken und hätte ja eigentlich keine zusätzliche Sicherheit. Denn der Salt soll das ja erschweren. |
Praktisches Beispiel:
Quelltext
1:
| user:$apr1$mNSgBsO6$2T.qjERxIQDVS649Df1d7/ |
Der Nutzername ist
user, das Passwort ist
foobar. Hash-Verfahren ist APR1 (eine MD5-Kaskade). Der Salt ist
mNSgBsO6 und der eigentliche Hash, der gebildet wurde, ist
2T.qjERxIQDVS649Df1d7/
Wie wird der Hash nun Gebildet: VOR dem Passwort wird der Salt-Wert als Präfix und noch ein paar Trennzeichen ergänzt. Danach wird das (mehrfach, bei APR1 sind das etwa 100 Durchläufe; wer Source sehen möchte, kurz nachfragen, dann such ich das raus; hatte hier im DF dazu mal was gepostet). Danach wird $apr1$salt$ und der gebildete Hash als ein Ausgabestring kodiert und als Ergebnis geliefert.
Zum Validieren eines solchen Hashes wird nun der String analysiert. Das erste $ sagt: Hier kommt ein Hash-Format, das apr1 gibt das Verfahren und der Rest wird halt auch noch zerlegt. Danach wird das für den Login übergebene Passwort mit dem aus der Passwort-Tabelle gelesenen Hash gehasht. Das Ergebnis wird anschließend verglichen. Bei Gleichheit stimmt das Passwort (wahrscheinlich.
Der Benutzername geht i.d.R. nicht mit in den Passwort-Hash ein. Vielmehr: Wenn man so paranoid ist, gibt es neben dem Passwort-Salt noch einen Nutzer-Salt, aber in keinem Fall sollte der Nutzername direkt in den Passwort-Hash einfließen, da man ansonsten "Known Plaintext" hat ;-) Um das zu Umgehen muss beim Hashen von Daten, die einem Angreifer bekannt sein könnten, darauf geachtet werden, dass der Angreifer nicht einfach herausfinden kann, wo der bekannte Text auftaucht. Ein Beispiel für soetwas wäre z.B. wenn man einen User-Salt generiert, aus diesem die Byte-Summe bildet und dann aus dieser die Position ermittelt, wo im nächsten Durchlauf ein Byte des Nutzernamens in den Zwischenhash eingesetzt wird. Das solange wiederholen, bis kein Zeichen vom Nutzernamen mehr übrig und den dann entstandenen Hash mit beim Passwort-Hash mit in den Salt einfließen lassen. Solange ein Angreifer den Salt hier nicht kennt, kann auch der User-Salt-Teil nicht berechnet werden.
Eine Steigerung dessen macht übrigens ispCP: Dort wird ein Salt und ein IV (Initialization Vector) außerhalb der Datenbank gespeichert: Wenn man nicht weiß, wo das zu finden ist, ist die Datenbank und die darin enthaltenen Passwörter vollständig wertlos.
| Dude566 hat folgendes geschrieben : |
| Wenn ich mich anmelde wird ja zunächst ein MD5 Hash meines Passworts und Benutzernamens generiert und dann mit den Daten aus der Datenbank abgeglichen, da bringt mir es ja nix beim erneuten Anmelden das er noch einen Salt in der Tabelle hat. Hoffe das ist verständlich wie ich das meine. :eyecrazy: |
Jap. Aber wie gesagt, ist das Vorgehen ein etwas anderes ;-) Der Salt wird aus der Tabelle gelesen (steht meist sogar direkt im Passwort-Feld ;-)) und dann wir mit dem Salt zusammen gehasht. Wenn dann der Wert aus der Datenbank wieder rauskommt, war's das richtige PW (oder eine sehr gute Kollission).
| schwandi hat folgendes geschrieben : |
| Hab mir jetzt nicht alles durchgelesen, aber habe vor kurzem von nem Prof. die Unterlagen eines 2 tägigen Kryptografier vortrages erhalten. |
Ich lege Dir das Buch mit der ISBN 978-3-411-04015-5 wärmstens ans Herz.
| schwandi hat folgendes geschrieben : |
| Wennst mir deine Email gibst kann ich sie dir schicken, da is sicher vieles nützliches dabei ;) |
Bitte entweder öffentlich posten, damit auch andere etwas davon haben, oder sein lassen. Wenn Du das aus rechtlichen Gründen nicht posten darfst, wird das i.a.R. auch via PN verboten sein ;-)
| Dude566 hat folgendes geschrieben : |
| Willst du es nicht vielleicht lieber direkt hier posten, dann hätten noch mehr Leute etwas davon die später mal auf diesen Thread stoßen. ;) |
Wäre ich dafür.
| Dude566 hat folgendes geschrieben : |
| Es sei denn, das darf nicht veröffentlicht werden oder so. |
Vermute ich mal stark.
schwandi - Do 17.02.11 10:18
Ich habe es nu am PC lokal, deswegen kann ichs nicht posten
Aber ich werds mal auf meinen Server laden und den Link hier posten :)
Dude566 - Do 17.02.11 11:23
Super Erklärung
BenBE, wenn ich weitere Fragen habe werde ich sie hier stellen. ;)
@
schwandi, man kann hier auch Dateianhänge erstellen. ;)
Fiete - Do 17.02.11 12:46
Moin Dude566,
ein sehr interessantes Buch zum Thema Kryptologie ist das Werk von Simon Singh Geheime Botschaften
Gruß
Fiete
schwandi - Do 17.02.11 14:31
^^ ok
Anbei sollten die Datein sein
lg
Dude566 - Mo 21.02.11 20:11
Hallo, ich melde mich hier mal wieder.
Ich bin jetzt am überlegen welches Verfahren der modernen Kryptographie ich exemplarisch miteinbringen könnte und wie ich es dann vll sogar als Beispielanwendung machen könnte.
In den Sinn kam mir, wie oben schon diskutiert wurde, dass ich einfach einen Benutzerlogin zu einer Seite mit "gesalzenem" MD5 mache.
Oder was würdet ihr mir vorschlagen?
BenBE - Mo 21.02.11 20:31
Wenn Du etwas Modernes haben möchtest, würde Ich Dir Sonys Implementierung für ECC (Elyptic Curve Crypto) empfehlen ;-) Dazu noch erklären, warum man NICHT den XKCD-RNG verwenden sollte und der Vortrag ist perfekt ;-)
Für Old-Fashioned geht natürlich auch ein Salted-Hash-MD5-Site-Login ^^
Dude566 - Mo 21.02.11 20:38
Gut ich möchte ja auch immer noch bei der Mathematik bleiben, habe mir überlegt vielleicht das Prinzip des RSA Verfahren zu erläutern.
Edit: Das ECC dürfte für einen Vortrag im Mathe-GK etwas overpowered sein aber anschauen werde ich es mir nochmal genauer. ;)
Sirke - Mo 21.02.11 22:33
Für einen Vortrag in der Schule ist ECC auf jeden Fall zu viel, da man zu viele Grundlagen vorweg erklären muss. Selbst RSA benötigt für einen Vortrag von rund 45 Minuten (?) bereits einen Haufen an Grundlagen: Restklassen, Invertierung, phi-Funktion und für den Beweis mindestens den kleinen fermatschen Satz!
Ich würde zu einem eher abstrakten Thema wie z.B. Salted Hashes greifen, weil man dabei ganz gut die Maßnahmen von "Angreifer" und "Verteidiger" gegenüberstellen kann!
Sofern es moderne Kryptographie im bereich der Zahlentheorie sein soll, würde ich zu Diffie-Hellman raten, weil man im Grunde nur die Restklasse als Grundlage benötigt und die Ordnung, phi-Funktion und Primitivwurzel weglassen kann. Im Vortrag kann man dann die Geschichte, den Algorithmus mit den Grundlagen, ggf das DH-Problem und die Verwundbarkeit durch den MITM Angriff samt Gegenmaßnahmen vorstellen.
Grundsätzlich könnte aber bereits ein Einstieg in die Krypto ohne das Verständnis von den vielen möglichen Primitiven zu viel sein bzw ein falsches Bild vermitteln!
Dude566 - Mo 21.02.11 23:27
Ja bisher habe ich erst einmal allgemeine Dinge mitreinbringen wollen, wie z.B. die Entstehung und die Ziele der Kryptographie und dann noch eine Übersicht der einzelnen Methoden.
Zur klassischen Kryptographie habe ich die Caesar-Chiffre mit Erklärung und Programmbeispiel, jetzt wollte ich halt noch ein Beispiel zur modernen Kryptographie.
Vortrag sollte insgesamt zwischen 15 und 20 Minuten gehen, weshalb ich dort eh nicht ins Detail gehen kann und daher nur die nötigsten Dinge zum Verständnis des Themas erwähnen werde.
Sirke - Di 22.02.11 00:27
Okay, dann würde ich auf jeden Fall zu DH raten! In meinen Augen ist das ein sehr einfach zu verstehender Algorithmus, der sehr gut die Macht der asym Krypto zeigt. Bereits mit kleinen Zahlen kann man gut sehen, dass man am Ende aufs gleiche Ergebnis (=gleicher Schlüssel) kommt und ein Angreifer der nur mithört nichts mir den Zahlen anfangen kann. Letzteres kann man gut verdeutlichen, indem man der Klasse einmal die Zahlen eines Angreifers bekannt gibt und sie den Schlüssel oder einen geheimen Teil der Kommunikation errechnen sollen. Bei guter Wahl und einem p > 25 sollte die Klasse damit schon gut beschäftigt sein und sofern das Interesse vorher gut geweckt wurde sollte es auch Spaß machen... ;-)
BenBE - Di 22.02.11 01:52
Dann kann man ja auch schauen, ob man CAESAR, LSFR und DH erklärt und daraus dann einen Strom-Chifre baut, der DH für den Schlüsselaustausch und CAESAR zur Verschlüsslung nutzt (wobei jeder Buchstabe mit einem anderen vom LSFR gelieferten Key verschlüsselt wird).
1. Schritt: DH-Key-Parameter generieren
2. Auf ein LSFR einigen
3. Schlüssel von DH-KEX als Startzustand des LSFR nehmen
4. Für jedes Zeichen 4 Bits vom LSFR generieren und dieses N+1 als Key für Caesar verwenden
5. Je ein Zeichen mit den so erzeugten Schlüsseln verschlüsseln.
6. Die mit 5. verschlüsselten Buchstaben bekanntgeben.
Dann kann Eve mal probieren, ob sie rausbekommt, was Alice und Bob sich mitteilen.
Dude566 - Di 01.03.11 23:59
Würde gerne mal wissen was eine Primitivwurzel ist, die Erklärung auf Wikipedia verstehe ich nicht. :(
BenBE - Mi 02.03.11 00:53
Primitiv-Wurzel ist grob vergleichen mit einem erzeugenden Element in einer Restklasse. Primitivwurzeln haben die Eigenschaft, dass wenn man diese mit allen Elementen einer Restklasse potenziert, sich alle Elemente dieser (außer der 0) darstellen lassen.
Bzw. wo genau liegt das Verständnis-Problem?
Dude566 - Mi 02.03.11 09:07
Was ist ein erzeugendes Element und was eine Restklasse?
Denke mal es hat irgendwas mit dem Divisionsrest von Primzahlen zu tun. :nixweiss:
BenBE - Mi 02.03.11 13:55
| Dude566 hat folgendes geschrieben : |
| Was ist ein erzeugendes Element |
Ein erzeugendes Element ist ein Representant einer Restklasse, mit dem sich alle anderen Elemente (außer der 0) durch wiederholtes Multiplizieren darstellen lassen.
Beispiel: 3 mod 7
3, 3*3 mod 7 = 2, 2*3 mod 7 = 6, 6*3 mod 7 = 4, 4*3 mod 7 = 5, 5*3 mod 7 = 1
| Dude566 hat folgendes geschrieben : |
| und was eine Restklasse? |
Ich zitiere hier mal die Wikipedia:
| Guttenlink [http://de.wikipedia.org/wiki/Restklasse] hat folgendes geschrieben: |
| Im mathematischen Teilgebiet der Zahlentheorie ist die Restklasse einer Zahl a modulo einer Zahl m die Menge aller Zahlen, die bei Division durch m denselben Rest lassen wie a. |
Aus dieser Menge nimmt man zum Rechnen üblicherweise den kleinsten, nicht-negativen* Vertreter.
| Dude566 hat folgendes geschrieben : |
| Denke mal es hat irgendwas mit dem Divisionsrest von Primzahlen zu tun. :nixweiss: |
Hat mit den Primzahlen nur nebensächlich zu tun. Bei Verwendung von Restklassenkörpern über Primzahlen Z/Zp ergeben sich halt nur eine Reihe bestimmter Eigenschaften, die man in der Kryptographie ausnutzt.
*Es gibt Mathematiker, für die ist 0 nicht positiv ;-)
Dude566 - Mi 02.03.11 21:15
Was ist denn mit allen anderen Elementen gemeint, also bei dem Beispiel 3 mod 7?
Achja, sollen das da unten mehrere Beispiele sein oder hängt das zusammen und damit sind die anderen Elemente gemeint.
Entschuldige wenn ich mich blöd anstelle. :oops:
Edit: Ich denke mal ich habe es verstanden.
Beispiel für die Primitivwurzel 3 von modulo 7:
3 ist die Primitivwurzel von modulo 7 weil alle Elemente der Restklasse von modulo 7 als Potenz von 3 wiederrum mit modulo 7 die Elemente 1 bis 6 ergeben.
Klingt wirr aber besser kann ichs nicht ausdrücken. Ist doch richtig so, oder?
BenBE - Do 03.03.11 02:04
| Dude566 hat folgendes geschrieben : |
Was ist denn mit allen anderen Elementen gemeint, also bei dem Beispiel 3 mod 7?
Achja, sollen das da unten mehrere Beispiele sein oder hängt das zusammen und damit sind die anderen Elemente gemeint.
Entschuldige wenn ich mich blöd anstelle. :oops:
Edit: Ich denke mal ich habe es verstanden.
Beispiel für die Primitivwurzel 3 von modulo 7:
3 ist die Primitivwurzel von modulo 7 weil alle Elemente der Restklasse von modulo 7 als Potenz von 3 wiederrum mit modulo 7 die Elemente 1 bis 6 ergeben.
Klingt wirr aber besser kann ichs nicht ausdrücken. Ist doch richtig so, oder? |
Korrekt.
5 ist die zweite. Primitivwurzel mod 7. Es gibt also nicht zwingend überhaupt eine, aber auch nicht nur zwingend eine einzige ;-)
Dude566 - Do 03.03.11 11:03
Na dann hoffe ich mal das ich das nachher in der Präsentation auch gut erklären kann.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!