Nachdem ich ein YouTube-Video auf dem Diffie-Hellman-Schlüsselaustausch gesehen hatte, wollte ich eine Implementierung in JavaScript ausprobieren (Atwoods Gesetz).
Ich habe eine Chiffre auf Node.js mit den folgenden Regeln entworfen:
Schritt 1: Client und Server vereinbaren einen gemeinsamen Schlüssel:
Kunde & amp; Server startet mit einem 512bit prime öffentlichen Schlüssel pK
Der Client generiert einen privaten 512-Bit-Primärschlüssel kC und sendet powMod (3, kC, pK)
Der Server generiert einen privaten 512-Bit-Primärschlüssel kS und sendet powMod (3, kS, pK)
Kunde & amp; Der Server verwendet powMod (response, privatekey, pK) als gemeinsamen Schlüssel
Schritt 2: Kommunikation
Bevor ein Client Daten sendet, wird er mithilfe der Stanford Javascript Crypto Library (256bit AES, HMAC Authentifizierung, PBKDF2 Passwortverstärkung und CCM authentifizierte Verschlüsselung) mit dem gemeinsamen Schlüssel verschlüsselt.
Sobald der Server die Daten mit dem gemeinsamen Schlüssel entschlüsselt, generiert er einen neuen privaten 512-Bit-Primärschlüssel und sendet ihn als SJCL-verschlüsselte Antwort.
Der Client und der Server wechseln mit powMod (3, prevSharedKey, newPrivKey) zu einem neuen freigegebenen Schlüssel
Jetzt habe ich ein paar Fragen ..
Wie sicher wäre ein solches System im Vergleich zu HTTPS oder anderen Algorithmen? Was sind die schwächsten Punkte eines solchen Systems?
In Bezug auf Sicherheit / Praktikabilität, wäre es besser, 1024-Bit-Schlüssel für stärkere Sicherheit zu verwenden? Sind die HMAC / PBKDF2 / CCM Optionen übertrieben? Lohnt es sich, den geteilten Schlüssel zu modulieren? Danke fürs Lesen!
Ich habe Fragen wie diese vorher gesehen - das ist völlig unsicher aus einer Reihe von Gründen , vor allem, weil es für einen JavaScript-Client unmöglich ist, den Schlüssel des Servers zu überprüfen ist authentisch.
Kurz gesagt, ohne SSL sind Sie anfällig für Man-in-the-Middle-Angriffe. Keine browserbasierte JavaScript-Krypto-Implementierung kann diese Tatsache überwinden.
Ihr System ist massiv unsicher, aber ich versuche nicht, Sie oder irgendjemanden davon abzubringen, mit solchen Dingen herumzuspielen. Du solltest weitermachen. Aber es ist wichtig, dass Sie alles, was Sie schaffen, als ein "Spielzeug" -System betrachten, das niemals als "sicher" betrachtet oder beworben werden sollte.
Teilen wir die Sicherheitsfrage in zwei Teile auf.
Lassen Sie mich zunächst (2) antworten, denn das wird am einfachsten sein. Es wird furchtbar unsicher sein, wenn Sie nicht schlauer sind als all die Leute, die im Laufe der Jahre TLS studiert und studiert haben. TLS vor der Version 1.2 (die nur wenige Sites verwenden) ist prinzipiell anfällig für Chosen Ciphertext Attacks (CCAs) und für die BEAST Angriff in der Praxis, abhängig von der Wahl der Chiffre. Und SSL 2.0 ist schlimmer kaputt.
Der Punkt ist, dass sehr sehr kluge Leute, die jahrelang an diesen Protokollen gearbeitet haben, einige Dinge falsch verstanden haben. Es gibt allen Grund zu glauben, dass Sie selbst an solchen Dingen arbeiten und große Fehler machen werden. Die grundlegenden Verschlüsselungsalgorithmen sind in Ordnung. Sie sind nicht kaputt. Aber die Protokolle sind.
Wenn Sie also nicht alle Details von SSL studiert und verstanden haben, warum sie dort sind und wie sie in einigen Fällen schief gelaufen sind, dann ist es fast sicher, dass jedes Protokoll, das Sie entwickeln, schrecklich sein wird.
Nun zu Frage (2). Es gibt zwei Probleme damit. (a) Diffie-Hellman ist nicht dafür ausgelegt, die Arten von Sicherheit zu bieten, die Sie wahrscheinlich benötigen; und (b) Ich denke nicht, dass Sie DH korrekt implementiert haben.
2.a:
Diffie-Hellman Der Schlüsselaustausch ist, wenn er richtig gemacht wird, für den Schlüsselaustausch sicher, aber er tut nichts zur Authentifizierung. Deshalb ist die Frage "ist es sicher" oft die falsche Frage. Es ist sicher für einige Zwecke, aber massiv unsicher für andere, da es nicht für diese anderen Zwecke konzipiert ist.
Josh3737 wies darauf hin, dass der Client und der Server nicht wissen können, dass sie mit dem Server sprechen richtige Partei. Wenn Sam der Server ist und Charlie der Client ist, gibt es nichts, was Mallory daran hindert, ihren eigenen Server einzurichten, der sich als Sam tarnt. Also kann Cathy den Schlüsselaustausch mit Mallory machen und denken, dass sie mit Sam spricht. Mallory kann vorgeben, Charlie zu sein, wenn er mit Sam spricht.Einmal so eingerichtet, kann Mallory als ein Mann in der Mitte zwischen Sam und Charlie agieren. Wenn Charlie Daten an Sam sendet, entschlüsselt Mallory sie mit dem geteilten Schlüssel zwischen C und M, liest ihn (und ändert ihn möglicherweise) und verschlüsselt ihn dann erneut mit dem gemeinsamen Schlüssel zwischen M und S und sendet ihn an S weiter .
Um das Authentifizierungsproblem zu lösen, benötigen Sie eine Art von Public Key Infrastructure (PKI) und diese sind wirklich ein Schmerz. Das System der Zertifizierungsstellen und das, was wir mit SSL / TLS haben, ist mit Problemen behaftet, aber es bleibt das beste System da draußen.
2.b:
Ein 512-Bit-Public-Modul zusammen mit privaten 512-Bit-Schlüsseln ist nicht stark genug. DH-Schlüssel müssen größer sein. Ich würde nicht mit weniger als 2048 Bits gehen. Sie könnten mit 1024 Bits davonkommen, Sie sind nicht besorgt darüber, dass jemand in fünf Jahren die Geheimnisse von heute brechen könnte.
Sie haben nicht genügend Informationen darüber gegeben, wie Ihre Primzahlen ausgewählt wurden. Nicht jede Prime funktioniert. Sie müssen eine "sichere Primzahl" für Ihr Modulo verwenden, andernfalls stehen einem Angreifer Verknüpfungen zur Verfügung, um den diskreten Logarithmus zu berechnen.
Wenn Sie das SSL-Cert und Mann im mittleren Problem umgehen wollen, können Sie die Bitcoin-Blockchain verwenden. (Oder eine Altcoin-Blockchain.)
Der große Nachteil: Der Client muss entweder eine komplette Datei der Blockchain herunterladen oder verwalten.
Es gibt zwei öffentliche / private Schlüsselpaare:
CERTpublic CERTprivate
CLIENTpublic CLIENTPrivate
NAME REGISTRIERUNG:
%Vor%VERBUNDENE VERBINDUNG:
%Vor%Tags und Links javascript node.js encryption aes diffie-hellman