Verschlüsselung ohne Passworteingabe / Passwortübermittlung

[OrallY]

Hallo.
Ich hatte vor einen kleine Chat zu schreiben, der eine verschlüsselte Verbindung benutzen soll, ohne dass beide Benutzer ein Passwort abklären, welches sie dann eingeben müssen.
Nun habe ich aber ein Problem: Um den empfangen Text wieder zu entschlüsseln, bräuchte der Empfänger ja auch das Passwort, mit dem es der "Sender" verschlüsselt hat. Wenn ich das Passwort in Klartext zuvor noch übermittle, brauch ich das ganze erst gar nicht zu verschlüsseln.
Natürlich kann ich auch das Passwort mit einem Alghorithmus verschlüsseln, der wiederum keinen Schlüssel benötig (z.B. ganz einfach XOR) oder einen stärkeren, aber einem statischen Passwort. Doch auch das könnte man blitzschnell durch disassemblierung entdeckt werden.
Ich hatte mir auch schon überlegt, ob ich Informationen wie IP und MAC usw. verwende, die dann zusammenwürfle und z.B. mit SHA verschlüssle. Doch hinter das System kommt man auch schnell und ist leicht nachzuahmen.

Wie könnte man dieses Problem lösen? Wie wird es bereits in Programmen wie z.B. Trillian gelöst?

[Phoenix]

Such mal nach Public Key Verfahren oder guck mal hier.

Der Trick ist, das Du einen asynchronen Algorithmus (z.B. RSA) verwendest. Die Algorithmen gibts soweit ich weiss auch in einer fertigen Implementierung bei Sourceforge.

Du erzeugst auf jeder Seite ein Schlüsselpaar (öffentlicher/public - key und privater/private key).

Der öffentliche Schlüssel wird nun an den Gegenüber verschickt. Diesen öffentlichen Schlüssel darf jeder abfangen, damit kann er nämlich nur Nachrichten VERschlüsseln.

Jede der Seiten verschlüsselt also die Nachrichten an den Gegenüber mit dessen öfentlichem Schlüssel. Zum ENTschlüsseln braucht nun das Programm seinen EIGENEN private Key. Dieser ist in der Lage, Nachrichten die mit dem dazugehörigen public Key verschlüsselt wurden wieder korrekt zu entschlüsseln.

Die Schlüsselpaare werden bei jeder Session neu erzeugt. Je nachdem wie sicher die Sache sein soll wählst Du halt entsprechend lange Schlüssel (40 bit sollten fast schon reichen, 128 sind imho schon zu stark - das dauert natürlich auch ne Weile das codieren und decodieren zu berechnen...).

Somit kannst Du sicher sein, daß wenn jemand dennoch den kompletten Traffic mitschneidet er für jede Session im Schnitt ein paar Jahre braucht, um nur die Kommunikation in eine Richtung zu lesen, für die andere Richtung gibts ja wieder einen anderen Schlüssel. Noch ein Vorteil von asynchronen Verfahren.

[anku]

Das mit dem Public Key ist schon mal ein guter Ansatz. In der Regel benutzt man Public Key Verfahren aber nur um einen sogenannten Session Key auszutauschen, welcher dann für das verschlüsseln der eigentlichen Daten benutzt wird.

Es kommen also zwei Verfahren zum Einsatz, einmal asymetrische Verschlüsselung (z.B. RSA) und einmal symetrische Verschlüsselung ( z.B. DES, AES). Die asymetrische Verschlüsselung ist recht zeitaufwändig und wird desshalb nur zum Schlüsselaustausch benutzt. (siehe z.B. SSL)

Für allgemeine Infos rund um Verschlüsselung und deren Knacken gibt es bei demCrypTool von der Deutschen Bank.

MfG

[negaH]

Zum sicheren Schlüsselaustausch in deinem Falle kommt meistens das Diffie Hellman Verfahren zum Einsatz. RSA wird dafür fast nie benutzt.

Gruß Hagen

[OrallY]

Danke für die Antworten. Werd das alles mal abchecken.
@negaH Was genau ist das Diffie Hellman Verfahren? Kennst du vielleicht schon eine Implementation in Delphi?

[negaH]

Das Diffie Hellman Verfahren dient zum sicheren Austausch von Geheimnissen über unsichere Kanäle. Diffie Hellman selber ist ein Professor Abgekürzt wird das Verfahren mit DH. Das gute an dem Verfahren ist es das es in jeder beliebigen Zahlendomain funktioniert die modulare Ringe zulässt. Also z.B. über normale Ganzahlen zu einem Primzahlring oder auch über GF(2^m) also Galois Fields in binären Feldern.

Wie arbeitet DH:
Zwei Parteien "Hagen" und "OrallY" wollen einen gemeinsammen sicheren Schlüssel erzeugen um damit im späteren Verlauf über eine öffentliche Leitung verschlüsselte Daten auszutauschen. Wichtig dabei ist es das dieser Schlüssel NICHT über die unsichere Leitung übertragen werden darf, d.h. der Schlüssel wird bei "Hagen" und "OrralY" erzeugt verlässt aber niemals die Computer von "Hagen" und "OrralY". Hier sieht man schon den Unterschied zu RSA.

Zitat:

1.) Hagen und OrallY haben sich auf zwei Zahlen geeinigt.
- große Primzahl (1024Bit) N, wobei (N-1)/2 ebenfalls prim ist, solche Primzahlen nennt man Sophie Germain Primzahlen
- Generator G, der modulo N primitiv ist, also auch Teilerfremd
- beide Zahlen können veröffentlicht werden, also auch über unsichere Leitungen übertragen werden

2.) Hagen wählt Zufallszahl S und sendet an OrallY den Wert X = G^S mod N.

3.) OrallY wählt Zufallszahl T und sendet an Hagen den Wert Y = G^T mod N.

4.) OrallY berechnet K = X^T mod N, wobei K das ausgetauschte Geheimnis ist.

5.) Hagen berechnet K' = Y^S mod N

K und K' == G^(S*T) mod N.

Man kann dieses Verfahren so abwandeln das Hagen z.B. sofort einen Schlüssel berechnet und damit auch eine Message verschlüsselt. Danach kann Hagen den Schlüsselaustausch und die verschl. Nachricht sofort an OrallY verschicken. OrallY wiederum kann den verwendeten Schlüssel erzeugen und die verschl. Message entschlüsseln. Eine Abart des DH Verfahrens das dies kann stammt von Hughes.

Beim DH Verfahren erkennt man schon zwei sehr Wichtige Dinge:
1.) alle sicherheitsrelevanten Paramter, also N und G sind öffentlich zugänglich und können verifiziert werden.
2.) alle Geheimnis tragenden Parameter, also S und T sind privat und einfache Zufallszahlen.

Beide Bedingungen treffen auf RSA eben nicht zu !

Zitat:

Kennst du vielleicht schon eine Implementation in Delphi?

Ja natürlich. Ich habe sogar schon 5 verschiedene Varianten selber programmiert. Allerdings mit meiner eigenen math. Library.



Gruß Hagen

[OrallY]

Wenn ich mal ganz doof fragen darf. Wie kann man eine 1024Bit große Primzahl erzeugen? Leben wir nicht in einer 32Bit Welt?

[Lillebrohr]

Guten Tag,

Muss ich das jetzt verstehen ?

du kannst auch eine 2048 bit große Primzahl erzeugen. Was du meinst sind die 32-bit Register. Oder ?


Die habe n aber nichts damit zu tuhen !

MfG

LB

[OrallY]

Nein, ich glaube das musst du nicht verstehen, da meine Frage aus meinem Unverständis heraus entstanden ist.
Kann mir bitte jemand erklären, was konkret eine 1024Bit große Zahl ist, da ich das offenbar irgendwie falsch verstehe...

//edit: Eine 1024Bit langer String besäße doch 128 Zeichen, oder? Irgendwie steh ich grad total aufm Schlauch und bin total verwirrt

[negaH]

Zitat:

Wenn ich mal ganz doof fragen darf. Wie kann man eine 1024Bit große Primzahl erzeugen? Leben wir nicht in einer 32Bit Welt?

Dazu benötigt man eine mathematsiche Bibliothek die mit solchen Zahlen rechnen kann. Mein eigene Entwicklung geht nun über 3 Jahre hinweg, und hatte zum Erfolg das sie zB. 1 Million Dezimalstellen von Pi als dritt schnellste PC Software der Welt errechnen kann.

Jede 32 Bit Operation, wie Addition,Subtraktion,Multiplikation usw. kann verkettet werden um 64,96,128... Bit Zahlen zu berechnen. Dafür haben die Konstrukteure der Chipsätze schon Sorge getragen.
D.h. statt nur 32Bit zu speichern, speichert man z.B. 32*32Bit hinereinander, also eine 1024 Bit Zahl. Alle Operationen werden nun auf 32Bit Operationen heruntergebrochen. Eventuelle Überläufe einer 32Bit Opration werden als Übertrag in die nächsthöhere 32 Bit Operation übernommen. Man kann sich das so vorstellen als wenn man 4 * 8Bit addieren wollte. Eine 32Bit Addition würde dann mit den 4 * 8 Bit's eines 32Bit Wertes das gleiche machen.

Hat man die Grundrechenoperationen einmal für beliebig große Zahlen programmiert, kann man nun die fehlenden mathematischen Algorithmen programmieren. Zum Erzeugen von "Primzahlen" benötigt man GCD() = Größter gemeinsammer Teiler, Modulare Inversionen per erweitertem GCD, die modulare Exponentation usw. Nun entwickelt man die Algorithmen zur "Primzahl" Erzeugung. Am häufigsten dürfte der Rabin Miller Test sein, der effizient aber nicht der optimalste Algo. ist. In meiner Library nutze ich einen "Strong-Lucas-Pseudo-Primzahl-Test" von Baillie-Selfridge-Wagstaff-Pomerance.
Man erzeugt also keine echten und eindeutigen Primzahlen, sondern sogenannte Strenge-Pseudo-Primzahlen. Die Wahrscheinlichkeit das eine so erzeugte 1024 Bit Zahl keine Primzahl ist, beträgt 1/2^1024. D.h. es kann durchaus vorkommen das eine solche "industrielle" Primzahl garkeine Primzahl ist. Zb. der Rabim Miller test lässt sogenannte Carmichel-Zahlen durch. D.h. der RM Test sagt bei diesen Zahlen das es eine Primzahl ist obwohl es keine ist. Der BSWP Test erkennt solche Carmichelzahlen. Seit Erfindung dieses Testes, 10 Jahren alt, hat man noch keine einzigste Nicht-Primzahl gefunden die diesen Test als Primzahl besteht. Man vermutet das die erste dieser Zahlen weit über 10.000 Bits groß sein muß. Promerance, einer der Professoren die dieses Verfahren analysierten, hat ein Preisgeld von 1.000 Dollar ausgesetzt für denjenigen der die erste solche Zahl findet. Bis heute hat er die Scheine noch


Gruß Hagen