OTP - Schlüsselübermittlung und Frage zur Sicherheit

[WIN-MANww]

Hi zusammen

Wollte euch mal Fragen, wie ihr bei einer OneTimePad Verschlüsselung, oder auch bei jeder anderen, den Schlüssel übertragen würdet? Das ist ja eigentlich die schwierigste Sache am OTP. Ich hätte mir gedacht, dass man den Schlüssel sicher einmal komprimiert, d.h. das man den Schlüssel per Algo in einen kleineren Schlüssel verwandelt, und dann beim Empfänger wieder in die ursprüngliche Grösse zurückrechnet. Jedoch denke ich liegt das Problem dabei, dass der Ausgangsschlüssel ja aus echten Zufallszahlen besteht, darum gibts keine Gesetzmässigkeit, nach welcher man den Schlüssel verkleinern könnte. Würde mich auch über Code zu dem Thema freuen. Als Zweites, wollte ich fragen, wieso beim OneTimePad mit Schlüssel = Länge der Nachricht der verschlüsselte Text nicht geknackt werden kann? Ich habe nämlich gehört, dass es darum nicht geknackt werden kann, weil der Rechner per Brute Force niemals den entschlüsselten Text findet, weil es jeder sein könnte. Jedoch ist das für mich nicht ganz verständlich, verschlüssle ich nun einen Text per XOR mit einem gleichlangen Schlüssel und verändere den Schlüssel nach dem chiffrieren, so erhalte ich beim dechifrieren meistens keinen richtigen Text, das heisst der Text besteht meist auch aus komischen Zeichen. Das heisst man würde doch merken, wanns geknackt ist, weil ja nur dann ein richtiger Text zum Vorschein kommt, oder nicht? Würde mich auch hier über Beispiele freuen. Danke schon im vorraus auf die, sicher, nützlichen Antworten. :)

[DGL-luke]

Zitat:

Jedoch denke ich liegt das Problem dabei, dass der Ausgangsschlüssel ja aus echten Zufallszahlen besteht, darum gibts keine Gesetzmässigkeit, nach welcher man den Schlüssel verkleinern könnte.

Exakt. Im Idealfall besteht er aus echten Zufallszahlen, und diese sind per definitionem unkomprimierbar.

Zitat:

Zitat von WIN-MANww

Als Zweites, wollte ich fragen, wieso beim OneTimePad mit Schlüssel = Länge der Nachricht der verschlüsselte Text nicht geknackt werden kann? Ich habe nämlich gehört, dass es darum nicht geknackt werden kann, weil der Rechner per Brute Force niemals den entschlüsselten Text findet, weil es jeder sein könnte

Es kommen beim Bruteforcen ALLE möglcihen Kobinationen, also auch ALLE sinnvollen, heraus. Z.B. kommen bei einer Nachrichtenlänge von 100 Zeichen mit 100% Wahrscheinlichkeit bei einem bestimmten Schlüssel die ersten 100 Zeichen von Hänsel und Gretel raus. Und genauso hundertprozentig die zweiten 100 Zeichen ;)

(du kannst Hänsel und Gretel gerne durch Die Bibel, das BGB, das StGB, die StVO, das GG oder HDR - Die zwei Türme ersetzen :mrgreen: - sogar gegen den Windows-Quelltext)

Sprich: Alles. Du kannst NIE den echten Klartext zwischen allen anderen Möglichkeiten herausfinden, es sei denn, es werden Teile des Schlüssels kompromittiert(Was die möglichen Lösungen evtl. drastisch reduziert).

Eigentlich genial, oder?

Zum Übertragen des Schlüssels würde sich ein asymmetrisches Verschlüsselungsverfahren eignen. Sprich, public key/private key. Da du ja aus dem public key, mit dem der Sender verschlüsselt, nie den private key, mit dem der Empfänger entschlüsselt, rausfinden kannst, ist so etwas auch sicher.

Am allersichersten ist es aber, für Schlüssel und Nachricht verschiedene Übertragungswege zu nutzen. Idealerweise ist ein Übertragungsweg physikalisch abhörsicher (->Quantenkryptographie) - wie viel Sinn das verschlüsseln der Nachricht dann noch macht, sei dahingestellt.

Was du allerdings NIE machen darfst, ist einen Schlüssel mehrmals zu verwenden. Sobald "der Feind" nämlich einmal Klartext und dazugehörigen Geheimtext erobert, kann er daraus (na, wie wohl? ;)) den Schlüssel errechnen.

¢ 2001-2006 Hagen Reddmann aka negaH, adaptiert

[negaH]

Die Ausführungen von Lukas haben eigentlich alles schon beantwortet, denoch möchte ich auf einen Punkt eingehen.

Zitat:

physikalisch abhörsicher (->Quantenkryptographie)

Ich bin nun wirklich kein Verfechter der sogeannten Quantenkryptographie, da es nur ein physikalisches "Experiment" oder besser eine Technologie darstellt.

Zitat:

wie viel Sinn das verschlüsseln der Nachricht dann noch macht, sei dahingestellt.

Und dieser Nebensatz ist wichtig.

Denn bei der Quanten-kryptographie geht es in keinem Falle um Kryptographie, sondern nur um die technologisch abhörsichere Übertragung von Informationen. Der Zusammenhang zur Kryptographie, also Wissenschaftszweig der Mathematik statt Physik, entsteht indem Moment das man über diese Quanten-Komunikation eben auch "ungeschützt" Schlüssel übertragen kann die zb. für einen OTP benutzt werden. D.h. statt mit mathematischen Verfahren ein Geheimnis geschützt zu übertragen versucht man dies mithilfe physikalischer Phänomene. Die Wahrscheinlichkeit ist als enorm viel größer das man diese physikalischen Apparaturen in der Zukunft brechen kann als die Wahrscheinlichkeit das man ein als sicher beweisbares rein mathematisches System brechen kann.


Zurück zum eigentlichen Problem:

Gehen wir mal davon aus das du wirklich einen echten OTP benutzt, also das was ein Kryptograph darunter versteht. Dann gibt es beweisbar kein einzigstes System das diese Sicherheitstufe je erreichen kann. Daraus folgt das die Übertragung des OTP Schlüssels in jedem Falle das gesamte System schwächen muß. Dh. für die Übertragung eines OTP Schlüssel kann selber nur ein noch längerer oder gleichlanger OTP Schlüssel eine adequat sichere Lösung darstellen. Da dies aber entweder praktisch unmöglich ist oder aber praktisch zu einer Endlosschleife ausartet, ist zwar die OTP Verschlüsselung mathematisch beweisbar die sicherste Verschlüsselung aber auch gleichzeitig praktisch unsinnig.

Angenommen du nutzt 1024 OTP Schlüssel und überträgst diesen zb. mit einen asymmetrischen Verfahren wie 1024 Bit RSA. Dann ist di Sicherheit des Gesamtystemes nur noch so groß wie das schächste Glied der Kette und das ist der RSA. Es macht also im Grunde wenig Sinn eine OTP Verschlüsselung zu benutzen.

Denn es gibt da ein klitzekleines Problem mit den OTPs: gibt es Zufall ? und wie können wir beweisen das der benutzte Zufall wirklich echt zufällig ist wenn es eine blöde Eigenheit von echtem Zufall ist das er nicht berechenbar ist, keine Formel hat und nicht reproduzierbar ist ? Aber gerade das dieser Zufall bei der Definition eines OTPs nicht mathematisch beweisbar ist stellt ein Makel dar. Dieser entzieht dem OTP als praktische Verschlüsslung jede Grundlage. OTPs bleiben also das was sie eigentlich sind, eine Hypothese, eine Idealisierung.


Gruß Hagen

[markusj]

Mal so am Rande ... das OTP kann man vorher verienbaren und unter sicheren Bedinungen austauschen, die Nachricht kann erst hinterher dazukommen.
Ein OTP übermittelt man im Regelfall nicht ... zumindest nicht wenns bei der Sicherheit eines OTPs bleiben soll, wenn du es per RSA übermittelst, ist dein Verfahren im Endeffekt nur noch mit der Sicherheit von RSA geschützt.

mfG

Markus

[Der_Unwissende]

[OT]

Zitat:

Zitat von DGL-luke

Idealerweise ist ein Übertragungsweg physikalisch abhörsicher (->Quantenkryptographie)

Leider nur Idealerweise, es ist erst neulich (weiß leider nicht mehr wo genau) gezeigt wurden, dass sich Photonen unter Umständen klonen lassen. Um es noch mal korrekter zu sagen, der Zustand eines Photons konnte auf ein anderes Übertragen werden ohne sich selbst zu verändern. All zu weit ist man da zwar noch nicht (der ist noch etwas instabil), aber es sind auch nur erste Schritte.
Spricht also einiges dafür, dass sich auch weiterhin Verschlüsselung für die Sicherung von Nachrichten anbietet.

Ach ja, ich dachte übrigens dass man einen Kanal der nur einzelne Photonen überträgt durchaus abhören kann. War der Sinn der Quantenkryptografie nicht nur es auch zu erkennen (nebst dass man nur bedingt die Information auswerten könnte).

Zitat:

Zitat von negaH

...als die Wahrscheinlichkeit das man ein als sicher beweisbares rein mathematisches System brechen kann

Stellt sich hier nicht wieder die interessante Frage wann ein System sicher ist? Sicher heißt doch irgendwie in dem Kontext nichts, oder? Wichtig ist doch nur die Frage wovor es sicher ist. Schließlich sind heutige Kryptografieverfahren (die natürlich total zu Recht eingesetzt werden) nicht absolut sicher, sondern nur sehr sehr sehr schwer rückrechenbar. Ok, damit meine ich auch nicht alle, XOR ist natürlich (eine von vielen) Ausnahmen, aber Asynchrone Verschlüsselungen werden doch in der Regel so gewählt, dass der Aufwand des Rückrechens zeitlich höher ist als die "Aktualität" (mir fällt gerade kein besseres Wort ein) der Information.
[/OT, sorry]

[negaH]

Zitat:

Mal so am Rande ... das OTP kann man vorher verienbaren und unter sicheren Bedinungen austauschen,

Hm. OTP = One Time Pad. Als Verschlüsselung bedeutet OTP

1.) echt zufälligs Password wähle das exakt so lang wie die nachricht ist
2.) ein OTP kann nur einmal benutzt werden
3.) jede Nachricht benutzt ihr eigenes OTP


Die Sicherheit des OTPs besteht eben auch darin das der zufällige OTP Schlüssel sewhr zeitnah zur Verschlüsselung gewählt wird, just in dem Moment also.

Die vorherige Vereinbarung eines OTPs entspricht also NICHT den Erfordernissen, noch ist sie überhaupt sinnvoll oer sicher. Auch kenne ich in der Praxis kein einzigstes Verfahren bei dem sowas gemacht wird, es wäre ja auch widersprüchlich.

Warum? Eben weil das sicherer Abspeichern eines OTPs nur geht wenn man den OTP wiederum mit einem anderen TP verschlüsselt. Was manchen wir aber mit diesem anderen OTP ? Wir erzeugen einesn dritten OTP mit dem wir den zweiten OTP vrschlüseeln der den ersten OTP verschlüsselt hat. H, was machen wir mit dem driten OTP ? einen virertn erzeugen ?

Jede andere Form der sicheren Speicherung eines OTPs muß beweisbar unsicherer sein. Speichert man den OTP also in einer SmartCard dann ist die Sicherheit dieser SmartCard bei weitem nicht mehr so hoch wie die des OTPs selber, also Sicherheitsverlust. Verschlüsselt man den OTP mit einem Password und Standardverfahren dann ist die Sicherheit maximal nur so groß wie das Standardverfahren und minima so groß wie die Qualität des menschlichen Passwortes, aber immer wesentlich kleiner als die des OTPs. Also wiederum Sicherheitseinbußen die den OTP ncht rechtfertigen.

Seleketiert man einen OTP im vorhinhein entsteht ein zweites Problem:

1.) echt zufälligs Password wähle das exakt so lang wie die nachricht ist

das bedeutet dann die eine Nachricht die man später verschlüsseln will muß in ihrer Länge schon im vorhinein bekannt sein. Sie kann defakto nur gleichlang oder kürzer dem OTP sein.

2.) ein OTP kann nur einmal benutzt werden

und das bedeutet wenn man in Zukunft 10 Nachrichten verschlüsseln möchte so müsste man auch 10 OTPs im vorhinein vereinbaren.

Wenn man einen OTP nun nicht "übermittelt" dann kann man als Empfänger auch nicht die geschützte Nachricht entschlüseln, logisch oder ? Also auch der Zeitpunkt in sich der Absender und der Empfänger eventuell sogar persönlich treffen und ihren gemeinsammen OTP vereinbaren ist eine Übermittlung. In diesem Prozess sind Datenträger involviert und deren beweisbare Sicherheit muß wiederrum weit geringer als die des OTPs sein. Also selbst bei der gmeinsammen Vereinbarung eines OTPs ist die Sicherheit der benutzten Medien der Übermittlung eine Merkmal das mathematisch beweisbar die Gesamtsicherheit reduziert, weit unterhalb der des theoretischem OTP.

Das sind alles Argumente die zeigen das OTPs unpraktisch sind, und sie werden in der Form auch nicht praktisch benutzt. OTP ist ein idealisiertes mathematisches Modell, mehr nicht.

Allerdings gibt es nun viele Verfahren und auch Dokumente die mit dem Wort "OTP" nur eine bildliche Umschreibung meinen. Selbst ich benutze in meinen SRP Code (hier in der DP downloadbar) den Begriff OTP. Im Zusammenhang damit das man mit einer Hash Funktion einen ephemeral Key erzeugt der dann mit Hilfe einer XOR Verschlüsselung wichtige temporäre Daten schützen soll. Diese Bedeutung eines OTP hat nichts mehr mit dem mathematischen OTP zu tuen, sondern mit der Namensgebung "One Time Pad" -> also Einmalschlüssel. Die Benutzung von OTP in diesem Kontext ist in der Kryptographie weit üblicher.

Zitat:

Leider nur Idealerweise, es ist erst neulich (weiß leider nicht mehr wo genau) gezeigt wurden, dass sich Photonen unter Umständen klonen lassen.

Neulich ist gut. Soviel ich weiß wurde schon 4 Wochen nach den ersten Veröffentlichungen der Quanten"kryptographie" per praktischem Expermient mehr als 20% aller beteilgten Photonen geklont. 20% Sicherheitsverlust nach 4 Wochen Forschung ist viel zu viel. Die theoretischen Erkenntisse der Mathematik im Beispiel RSA und Faktorization von Primzahlen wurden in den letzten 30 Jahren nicht annähernd widerlegt nocht gebrochen. Die Möglichkeiten und Erkentnisse schneller Faktorisieren zu können sind im Vergleich zu den gewählten Sicherheitsschranken im RSA geradezu lächerlich. Interpoliert man das mal dann heist dies das die Menschheit erst in Millionen von Jahren den Wissenstand und die Technik besäße heutige RSA Schlüssel zu knacken. Nun vergleiche das mal mit 4 Wochen und 20% Photonen.

Wissenschaftler benötigen Geld, und deshalb erzeugen sie öfters wie Marketingleute Hoffnungen, öfters unwissenschaftlich begründete.

[qoute]
stellt sich hier nicht wieder die interessante Frage wann ein System sicher ist?
[/qoute]

Ja immer. Einfach gesagt immer dann wenn wir mit rein Mathematischen Methoden dies 100% exakt beweisen können. Ist dies der Fall dann gilt dies aus Sicht der Mathematik für alle Zeiten, für alle Intelligenzien und für alle Universen, solange unsere Axiome die unsere Mathematik ausmachen weiterhin die gleichen sind ! Zum Glück wurden die wesntlichen Axiome der Mathematik in den letzten Jahrtausenden eher immer wieder als beste Annahme bestätig statt als falsch widerlegt ;)

Das heist: wenn wir heute eine System als matheamtisch sicher beweisen können dann könen wir durch das weitere Wissenswachstum in der Zukunft der Menschheit nur an Sicherheit dazu gewinnen. Denn egal ob wir dann ein System als weiterhin sicher beweisen können oder als unsicher bewiesen haben, in beiden Fällen wissen wir und gewinnen auf Grund der wissenschafltichen Vorgehensweise immer neue Erkenntinisse die uns die Anwendung des Sytemes sicher macht. Denn wenn wir zb. bweisen könnten das RSA unsicher wäre, als mathematischer Beweis, so können wir uns sicher sein das wir ein neues System benutzen müssen und RSA eben just unsicher ist. Wir schützen dann eben unsere Daten mit anderen Systemen. ABER! wir wissen es in diesem Moment und glauben/vermuten es nicht nur.

Der Unterschied zwischen Physik und Mathematik ist nun das die Physik abhängig von den Gesetzten unseres Universums ist. Das Universum überascht die Physiker immer wieder und ständig müssen grundsätzliche Theorien verworfen werden. Das kann daran liegen das die Physiker nicht genügend Wissen besitzen, könnte aber auch daran liegen das das Universum durch einen Gott erschaffen wurde und diese Intelligenz ist uns unendlich weit überlegen also im Endeffekt für uns nicht erfassbar.

Die Mathematik aber geht von garnichts aus, bzw. sie ist von allem unabhängig wahr. Die Menschen stellen dabei einfach par Behauptungen auf, sprich Axiome, und schauen was sich daraus mit reiner Logik für Konsequenzen ergeben. Unsere Mathematik ist also ein absolutes Gedankengebäude und rein logisch. In den Formeln der Mathematik ist kein Zufall enthalten (das Wissen ist also nicht zufällig), es ist beweisbar. Wenn also ein kryptrographisches Verfahren mathematisch als unsicher eingestuft werden muß dann heist dies wir haben mehr Wissen erlangt ergo mehr Sicherheit.

Das nun die Behauptungen der Mathematik frapierende Übertragungen in unsere Realität besitzen, sprich die Mathematik erklärt unsere Umwelt, beweist nur das der Weg den die Mathematiker gehen richtig ist und die aufgestellten Axiome in der Lage sind unsere Realität mathematisch korrekt zu beschreiben. Das müsste aber so nicht sein und interessiert den Mathematiker im Grunde auch nicht. Das gefährliche daran ist nun das es keine Nische für einen Glauben in der Mathematik gibt, bzw. in der Arbeitsweise der Mathematik. Man könnte sehr wohl Axiome aufstellen die mathematisch alles erklären könnten, also auch einen Gott, aber in der Arbeitsweise dieser Aufstellung der Axiome gibt es nur Logik und Erkenntnisse in Form von Wissen.
Und exakt diese Arbeitsweise ist es die die einzigst Richtige in der Krypütographie ist, denn nur dadurch erlangen wir tatsächliche Sicherheit -> Wissen.

Wenn es also Wissenschaftler gibt die behaupten das ein Gott/eine Intelligenz unser Universum erschaffen hat, ein Axiom, und dann darauf aufbauend mit der gleichen logischen Arbeitsweise eines Mathematiker JEDEN Punkt ihrere Behauptung beweisen können UND dann ich sehe das sich damit meine subjektiv erfasste Realität erklären lässt, dann bin ich absolut bereit an einen Gott zu glauben. Es ist mir dann egal ob Gott oder nicht, das was für mich immer nur zählt ist das aus Sicht meines Wissens es logisch betrachtet nur so oder so sein kann. So arbeitet auch die Kryptographie.

Gruß Hagen

[DGL-luke]

Zitat:

Zitat von Markusj

das OTP kann man vorher verienbaren und unter sicheren Bedinungen austauschen

Nur als Bemerkung am Rande...soweit ich weiss war es im 2. Weltkrieg üblich, sogenannte "Schlüsselblöcke" auszugeben, in denen für bestimmte Zeitpunkte (tagesweise o.ä.) Schlüssel für Nachrichten vereinbart waren. Wenn die Gegenpartei einen solchen erobert hat, war natürlich alles im Eimer...

[negaH]

@Lukas:

das war ja auch dann der Fall, oder ;)

Die Technik der "Codebooks" gilt heutzutage als nicht modern und unsicher. Heutige Verfahren würden Code Bücher benötigen die kein Mensch jemals irgendwie auf Datenträger speichern könnte, weil sie einfach zu groß sind.

Dh. aber nicht das es unter Umständen sehr wohl solche Anwendungen noch gibt. Das schöne ist es ja das wir heutzutage das Wissen der Generationen vor uns und unser eigenes neues Wissen besitzen. Wir haben also die größere Freiheit exakt die Methode zu wählen die auf ein Problem passt, egal ob alt oder neu, hauptsache im gesteckten Rahmen ausreichend sicher, beweisbar.

Gruß Hagen

[WIN-MANww]

Ok, das gibt zwar theoretisch gute Antworten auf meine Fragen, nur steht mir so etwas wie Quantenkryptographie nicht zur Verfügung. Also, mir geht es darum, ein Kommunikationssystem, einen Chat, zu programmieren, der die Nachrichten möglichst sicher übertragen kann. Dabei kann auch die Performance darunter leiden, d.h. es darf auch mal ein bischen länger dauern, bis eine Nachricht übermittelt ist, jedoch soll die Handhabung schlussendlich einfach sein und das Ganze soll nur in Form einer Software vorhanden sein. Da ein OTP ja echte Zufallszahlen braucht ist das nochmal ein Problem, denn wie kann ich echte Zufallszahlen ermitteln? Per Aufzeichnung der Mausbewegungen? Naja, das wäre aber auch unpraktisch, weil der Benutzer so bei jeder Übermittlung die Maus zuerst eine Weile hin und her bewegen müsste (je nach Textlänge). Würden es nicht auch gute Pseudozufallszahlen tun? Klar, es wäre damit nicht mehr unknackbar, jedoch habe ich sowieso noch das Problem mit der Schlüsselübermittlung, da die ja bei jeder Nachricht erfolgen muss. Ich will von euch nun wissen, was ihr in dem Fall für die Übermittlung und die Verschlüsselung vorschlagen würdet? Ich würde nämlich gerne ein OTP verwenden, weil es doch auch ziemlich schwierig zum knacken ist, auch wenn man Pseudozufallszahlen verwendet. Danke

[DGL-luke]

Ich würde da PGP empfehlen.

[Ratte]

Dafür dürfte ein OTP nicht sonderlich gut sein (Du kannst natürlich jedem deiner Partner 1GB OTPs auf DVD geben und dann damit arbeiten, ist aber glaube ich nicht sonderlich clever. Du solltest lieber ein asymetrisches Verfahren nehmen (RSA). Allerdings kannst du natürlich in etwa wie bei PGP (überträgt keine OTPs, sondern "normale Schlüssel") den OTP per RSA verschlüsseln und dann so übertragen. Ist dann aber auch nur so sicher wie RSA (quasi unknackbar).
mfg,
Ratte

[negaH]

Schau mal hier in die CodeLib meinen SRP an.

SRP = Secure Remote Password Protocol ist ein Authentifikations und Schlüsselaustausch Protokoll. Dabei geht es also darum das sich ein Client bei einem Server anmelden kann, beide sich gegenseitige authentifizieren, sprich überprüfen ob am anderen Ende auch wirklich der berechtigte User sitzt, auf sicherer Art einen gemeinsam mmen Schlüssel erzeugen und damit dann ihre spätere Kommunikation verschlüsseln können. Wichtig bei all diesen Aspekten ist es das kryptographisch sicher verhindert wird

1.) das Password des Clients zu knacken
2.) das Password in keinster Weise jemals über den unsicheren Kanal übertragen wird
3.) eine Man in the Middle Attacke ausgeschlossen ist, unmöglich wird
4.) beide Parteien genau wissen das am anderen Ende derjenige ist für den er sich ausgibt
5.) ein sicheres Session-Password -> Shared Secret gemeinsam berechnet wird das zufällig ist, nicht über den unsicheren Kanal übertragen wird so das man es eventuell knacken könnte, dieser Sessionkey ausreichend groß ist >= 256 Bit.

Eventuell würde der SRP also nicht nur deine Anforderungen auf kryptogaphisch sichere Weise erfüllen sondern sogar dein Chat Program noch zusätzlich durch weitere bessere Feature aufwerten.

Gruß Hagen

[DGL-luke]

Zitat:

Zitat von negaH

3.) eine Man in the Middle Attacke ausgeschlossen ist, unmöglich wird

Wie soll das gehen?

Sobald am Router oder sogar an einem der PCs oder am Server jemand alles mitloggt bzw. als man in the middle arbeitet (sprich alles abfängt und nach gutdünken weiterleitet), hat er doch alle Informationen die er braucht, um den kompletten Verschlüsselungsvorgang nachzuvollziehen.

Rein theoretisch ist doch eine man in the middle attack IMMER möglich, solange man eine solche Zwischenstation nicht auschließen kann (und im Internet kann man das nie)

(Ich hoffe, das ist nicht zu sehr OT)

[negaH]

Die MITMA ist ausgeschlossen, ansonsten würde SRP keinen Sinn machen, und viele andere Protokolle ebenfalls nicht.
Und es geht indem man Kryptographie benutzt. Genauer gesagt benutzt man die Technik des "Zero Knownledge" Protokolls. Dabei geht es darum wie man beweisen kann das man ein Geheimnis kennt OHNE dieses Geheimnis verraten zu müssen.

Also wenn es ein Verfahren gibt mit bei dem ich sage "Ich weis ein Geheimnis und kann dies dir beweisen OHNE das DU mein Geheimnis kennen musst" dann nennt sich das "Zero Knownledge", da DU keinerlei Informationen von mir über das Geheimnis selber erhältst. Wenn du aber keine Informationen über mein Geheimnis von mir erhälst so impliziert die auch das kein Anderer Informationen über mein Geheimnis erhält, also auch nicht der böse MITMA.

Es hört sich im ersten Moment als eine Unmöglichkeit an ist aber dank schlauer Mathematiker tatsächlich machbar.
SRP baut darauf auf oder Diffie Hellman Schlüssel Austausch baut indirekt darauf auf.

Allerdings gibt es tatsächlich einen, und einzisgten Zeitpunkt in dem eine MITMA möglich ist, immer, und bei jedem Protokoll. Nämlich der allererste Schritt in dem ein Client beim Server als berechtigter Client registriert wird. Bei jedem Protokoll ist dies eine Schwachstelle und lässt sich im Grunde nur durch eine Dritte Partei -> Trust Center oder direkte Authenfikation (persönlich) lösen.

Wurde dieser erste Schritt sicher abgearbeitet dann sind alle nachfolgenden Schritte garantiert MITMA sicher.
In diesem ersten Schritt ist es über das Zero Knownledge nun möglich das der Server und Client einen sogenannten Verifier vereinbaren/austauschen der denoch nichts über das Geheimnis=Password aussagt. Ganz stimmt diese Aussage aber nicht ;) Denn korrekt betrachtet ist der Verifier eine Zahlenmäßige Umformung diese Passwortes die mit heutigem Wissen und technologischen Möglichkeiten nicht in das Passwort zurückgerechnet werden kann. Dieser Verifier wird nun zb. im laufenden Protokoll des SRPs niemals übertragen. Der Client/Server können sich aber denoch mit Hilfe des Zero Knownledge gegenseitig davon überzeugen das der jeweils andere diesen Verifier kennt.

Der Client wird einfach mit Hilfe vom SRP aus seinem Password diesen Verifier reproduzieren, der Server hat den Verifier gespeichert. Beide tauschen beim Login nun verschiede Werte untereinander aus die dann indirekt einen Beweis ergeben das der jeweils andere den Verifier kennen muß.

Man geht dabei immer davon aus das sowohl der Client wie auch der Server sicher sind. Wurde also ein Server kompromittiert und hijacked dann ist natürlich eine MITMA möglich. Politisch betrachtet ist das auch ein Grund warum in Deutschland per Verordnung ein Provider gesetzlich verpflichtet ist eine Standleitung zum BND einzurichten, quasi jeder Provider hijacked werden kann. Allerdings trifft dies eben nicht auf Endstellen zu, also Clients und Clients die als Server arbeiten. Und gerade deswegen ist es gut das es solche Protokolle gibt, sie verhindern nämlich eine MITMA effizient.

Bei SRP geht man noch einen Schritt weiter. Im Verlauf des Protokolls authentifizieren sich der Client und Server gegenseitig und erzeugen nebenbei sogar noch ein sogenanntes "shared Secret", einen gemeinsammen Schlüssel. Mit diesem kann dann später ohne Probleme die Kommunikation verschlüsselt werden. Bei diesem Schlüsselaustausch, bei dem keine Schlüssel "ausgetauscht" werden, sondern beide zur gleichen Zeit einen gemeinsammen Schlüssel berechnen, werden wiederum keine nützlichen Informationen übertragen die Rückschlüsse auf diesen Schlüssel ergeben. Ein MITMA kann also nicht diesen Schlüssel durch Lauschen nachberechnen.
Dieser Schlüssel ist dann auch noch zufällig gewählt, und verhindert durch seine binäre Größe jede Brute Force Attacke.

Mein Counter-SRP geht noch par Schritte weiter als Standard SRP. Counter-SRP ermöglicht es zu jedem Login ein neues Password zu vereinbaren ohne das dies übertragen wird und ohne das der Server wissen kann wie das Password lautet oder sogar mit der noch restriktiveren Einschränkung das der Server noch nichtmal in der Lage ist zu erkennen OB das Passwort geändert wurde oder nicht !

Einzigst der Server, als böser Server, wäre in der Lage eine Brute Force Attack auf das Client-Passwort durchzuführen. Allerdings bei gutem Passwort und öfterer Änderungen des Passwortes ist das praktisch nicht machbar.
Desweiteren benutzt Counter-SRP noch nichtmal einen lesbaren Client Namen. D.h. Counter-SRP könnte völlig anonyme Clients verwalten. Selbst wenn also der Server gestohlen würde so wüssten die Angreifer nicht welcher Datenbank-Record zu welchem Clienten gehört. Das ginge wiederum nur durch eine Brute Force Attacke oder besser per Dictionary Attack -> Wörterbuch Angriff. Selbst wenn dies erfolgreich machbar wäre dann muß man immer noch das Clientpasswort per Brute Force Attacke brechen. Allerdings geht dies diesesmal nicht mehr per Dictionary Attack, der Angreifer muß also für jedes Paswort real eine komplette Brute Force Attack durchführen. Das wären bei meinem Counter-SRP also 2^256 * Password_Länge_In_Bits Kombinationen die man durchprobieren muß !


Gruß Hagen

[DGL-luke]

Danke. Sehr aufschlussreich.

[WIN-MANww]

Hi zusammen

Danke für die Antworten, das mit dem SRP werd ich mir noch überlegen. Ich interessiere mich jetzt vor allem für das Public Key Verfahren, nur will ich es nicht so richtig begreifen, wie es funktioniert. Habt ihr vieleicht zufällig ein Stück Code, an welchem ich sehen kann, wie ein Public Key Verfahren zwischen einem Server und einem Client funktioniert? Würde mich sehr darüber freuen.

[WIN-MANww]

*push* Keine Ahnung ob es jetzt schon erlaubt ist, aber ich hoffe mal schon.

[generic]

warum willst du das rad neu erfinden.
tunnel deine komunikation du ssh/tls oder ein vpn.

[WIN-MANww]

Danke für die Antwort

Sagen wir es so, ich sollte es besser neu erfinden, denn dieser Chat soll ne Projektarbeit werden und ich muss das Ganze dann auch noch dokumentieren, daher wäre es besser, ich würde soviel wie möglich selber schreiben. Meine Vorstellung ist einfach, einen Chat zu schreiben, der die nötige Sicherheit beinhaltet, d.h. er soll so sicher wie möglich, aber trotzdem noch benutzerfreundlich werden, daher denke ich ist ein Public Key Verfahren ziemlich sinnvoll.

Habt ihr also ein bischen Code für mich über Public Key Verfahren? Würde mich sehr freuen.

[WIN-MANww]

Nochma, n *push*