nicht angemeldet
Re Hi,
Hört sich interessant an.
Aber grundsätzlich noch folgende Fragen:
- Soll es wirklich ein assymetrisches Verfahren sein oder reicht auch ein symmetrisches Verschlüsselungsverfahren?
Es MUSS ein assymetrisches Verfahren sein. Mit dem Public-Key, der im übrigen ruhig "ungesichert" übertragen werden darf, kann nur VERSCHLÜSSELT werden. Das heißt, wenn ein Angreifer diesen kennt, kann er zwar Nachrichten verschlüsseln, diese dann aber nicht (mit diesem Key) wieder entschlüsseln.
NUR mit dem Private-Key, der entweder "sicher", d.h. zugriffbeschützt auf dem Server liegt, oder sicher bei mir auf der lokalen Platte, kann ich die mit dem Public-Key verschlüsselten Nachrichten wieder entschlüsseln. Den darf natürlich keiner kennen, sonst ist die Sache witzlos.
- Wie und wo wird bei einem assymetrischen Verfahren das Schlüsselpaar Private-/Public-Key generiert?
Wie, das ist die Frage des verwendeten Algorythmus. Ob er z.B. Datum, Uhrzeit, Usernamen etc. beinhaltet, ist in sofern nicht ganz so wichtig. Wichtig ist nur, daß der Key auf einer Basis generiert wird, die von einem potentiellen Angreifer nicht zu "erraten" bzw. zu ermitteln ist (was nicht heißt, daß er den Algorythmus nicht kennen darf - wobei ihm die Sache das etwas erleichtet).
- Wie gelangt in diesem konkreten Anwendungsfall der Public-Key zum Empfänger der Nachricht (Server?)?
Der Empfänger der Nahricht benötigt den Public-Key zum Entschlüsseln nicht. Er benötigt nur den Private-Key. Und der liegt ja sicher auf dem Server.
Falls Du mit Empfänger den User meinst, der die verschlüsselten Daten übertragen will, so ist dies ganz einfach: Der Public-Key wird ungesichert im Quellcode übertragen, ebenso wie der Algorythmus zum VERSCHLÜSSELN.
Da nämlich die Übertragung des Public-Keys auch gesichert erfolgen müsste, könnte doch auch einfach ein symetrisches Verfahren mit nur einem Schlüssel eingesetzt werden.
Da liegt der Kern des Problems. Wenn ich nur einen Schlüssel habe, den ich zum ENT- und VERSCHLÜSSELN einer Nachricht verwende, muß der Schlüssel geheim, oder vielmehr sicher übertragen werden. Da das ja nicht möglich ist, ist diese Methode pinzipiell ungeeignet.
Machen wir das ganze an einem Beispiel fest:
Ich generiere mit Algorythmus 1 (A1) und einer frei wählbaren Codebasis (z.B. "123") einen Public-Key (PK) (z.B. "321") und einen Private-Key (OK) (z.B. " 213").
Der PK ist im Quelltext der Datei eingebettet, die zum User ungesichert übertragen wird.
Der User verschlüsselt dann seiner Nachricht (z.B. "toll") mit PK
und Algorythmus 2 (A2) verschlüsselt (Ergebnis: "t3o2l1l").
Diese so verschlüsselte Nachricht wird dann zum Server übertragen (ungesichert, denn eine gesicherte Verbindung haben wir ja nicht). Diese verschlüsselte Nachricht kann dann auf dem Server NUR mit dem OK und Algorythmus 3 (A3) wieder entschlüsselt werden. Das heißt auch wenn jemand den PK kennt, kann er die Ncahricht nicht entschlüsseln.
Und ich habe dann wieder auf dem Server die entschlüsselte Nachricht.
Leider funktioniert das ganze nur in eine Richtung (zum Server hin) gesichert. Das stellt aber im Gegensatz zur bereits vorgestellten (und vor allem mit JS verwirklichten) MD5-Verschlüsselung in sofern einen Fortschritt dar, daß man codierte NAchrichten wieder entschlüsseln kann, was ja mit der MD5 Methode NICHT geht. Bei MD5 kann man verschlüsselte Strings nur vergleichen und so sagen, ob die ursprüngliche Nachricht übereinstimmt. Das reicht für einen Passwortschutz sicher aus, aber um z.B. Kontonummern oder Kreditkartennummern sicher zu übertragen nicht. Da ich ja nicht verschlüsselte Kartennummer bracuhe, sondern die entschlüsselte.
Ich hoffe, meine Idee ist nun richtig verstanden worden. ;)
Bin gespannt, in welche Richtung sich das Ganze entwickelt.
Ich auch ;)
Viele Grüße
Alexander