Client-side-Verschlüsselung über HTTP mit Diffie-Hellman Key Exchange und AES

Nachdem ich ein YouTube-video auf der Diffie-Hellman-Key-Exchange, ich wollte versuchen, eine Implementierung in JavaScript (Atwood ' s law).

Ich entwarf eine Chiffre auf Node.js mit den folgenden Regeln:

  • Schritt 1: Client und server einigen sich auf einen gemeinsamen Schlüssel:

    • Client & server starten mit einem 512bit prime öffentlichen Schlüssel pK

    • Client generiert einen 512bit prime private Schlüssel kC und sendet powMod(3, kC, pK)

    • Server generiert ein 512bit prime private Schlüssel kS und sendet powMod(3, kS, pK)

    • Client & Server verwenden powMod(Antwort, privatekey pK) als gemeinsamen Schlüssel

  • Schritt 2: Kommunikation

    • Bevor ein client Daten sendet, verschlüsselt mit dem gemeinsamen Schlüssel unter Verwendung des Stanford Javascript Crypto Library (256bit AES, HMAC-Authentifizierung, Passwort, PBKDF2 Stärkung und CCM-authenticated-encryption.)

    • Sobald der server entschlüsselt die Daten mit dem gemeinsamen Schlüssel, erzeugt es eine neue 512bit prime privaten Schlüssel und sendet es als SJCL die verschlüsselte Antwort.

    • Client und server wechseln zu einem neuen gemeinsamen Schlüssel mit powMod(3, prevSharedKey, newPrivKey)

Nun habe ich ein paar Fragen..

Wie sicher wäre ein solches system werden im Vergleich mit HTTPS oder andere algorithmen? Was sind die schwächsten Punkte von einem solchen system?

In Bezug auf die Sicherheit /Funktionalität, würde es besser sein, auf 1024-bit-Schlüsseln für mehr Sicherheit? Sind die HMAC/PBKDF2/CCM-Optionen-overkill? Lohnt es sich die Modulation der gemeinsame Schlüssel? Vielen Dank für das Lesen!

InformationsquelleAutor iRyanBell | 2012-03-23
  1. 8

    Ich habe gesehen, Fragen wie diese vor – das ist völlig unsicher für eine Reihe von Gründen, vor allem ist die Tatsache, dass es unmöglich ist für ein JavaScript-client, um zu überprüfen, dass der server-Schlüssel authentisch ist.

    Kurz gesagt, ohne SSL, Sie sind anfällig für man-in-the-middle-Angriffe. Keine browser-basierte JavaScript-crypto-Implementierung überwunden werden können, diese Tatsache.

    • Hrmm. Vorausgesetzt, ich könnte das javascript läuft auf dem client-Rechner mit der zuversicht, dass es noch nicht geändert wurde (evtl. unmöglich), wäre es nicht weniger unsicher? Ich glaube nicht, dass änderungen an den Daten (ohne die applet-Auslieferung) würde Sie gefährden.
    • Praktisch gesprochen, ist der einzige Weg, um JS auf dem client in einer vertrauenswürdigen Art und Weise, ist über SSL. Und da Ihre Verbindung ist schon gesichert, was ist der Punkt, zu tun, Ihre eigenen Krypto-an diesem Punkt?
    • Neuverhandlung Attacken: openssl.org/news/secadv_20091111.txt, lwn.net/Articles/362234 - Chiffre-downgrade-Attacken: openssl.org/news/secadv_20101202.txt, wroot.org/posts/preventing-your-servers-from-downgrade-attacks
    • der Punkt sein könnte, host-proof-hosting (ajaxpatterns.org/Host-Proof_Hosting), zum Beispiel. Safe an der Art, wie Passwort-manager. Aber das mag nicht relevant sein, im obigen Fall.
    • Er sagte nie etwas über seine Arbeit als browser-basiert. Er sagte ausdrücklich schreibt er dies in node.js. Auch wenn er nicht wusste, er könnte in einer Reihe von anderen Orten und offline-Anwendungen. Ignorierte seine Frage und sagte ihm, dass es völlig unsicher ist sehr unproduktiv.
    • Dies ist eine ziemlich Konstruktive Antwort, und sollten nicht akzeptiert werden. Das Problem der source code Provenienz ist orthogonal zu jeder möglichen Themen rund um das schreiben DH in JS. Diese Antwort ist ein Paradebeispiel einer "middlebrow Entlassung": news.ycombinator.com/item?id=4693920. Snarky genug bekommen upvotes, noch hinzufügen, nichts zu der Diskussion.
    • -1 schrecklich und snarky Antwort. Die beschriebene Regelung ist eine massive Verbesserung über plain HTTP, da es angreifen erfolgreich, es erfordert eine aktive man-in-the-middle-Angriff. In anderen Worten, es ist nur compromisable wenn einige router auf dem Weg kompromittiert ist. Ja, nicht ideal, aber nicht gerade üblich -- Wann war Sie das Letzte mal erlebt, gefälschte DNS-Antworten, zum Beispiel? Die Frage verdient eine richtige Antwort.

    InformationsquelleAutor josh3736
  2. 16

    Ihrem system ist Massiv unsicher, aber ich werde nicht versuchen, Sie davon abzubringen oder jemand aus einem Spiel mit Sachen wie diese. Sollten Sie sich weiter. Aber es ist wichtig, dass Sie alles in Betracht ziehen, die Sie erstellen ein "Spielzeug" - system, das sollte nie angesehen werden oder eben als "sicher".

    Lassen Sie uns brechen die Sicherheits-Frage in zwei Teile.

    1. Wie sicher der key exchange?
    2. Wie sicher ist die Verschlüsselung Sie verwenden, sobald Sie haben einen gemeinsamen Schlüssel?

    Lassen Sie mich die Antwort (2) erst als das wird das einfachste sein. Es wird furchtbar unsicher, es sei denn, Sie sind klüger als alle Menschen, die gearbeitet haben, auf und studierte TLS im Laufe der Jahre. TLS vor der version 1.2 (die paar Seiten verwende), ist anfällig für Chosen Ciphertext Angriffe (CCAs) im Prinzip und die UNGEHEUER-Angriff in der Praxis je nach cipher suit Wahl. Und SSL 2.0 ist mehr kaputt.

    Der Punkt ist, dass sehr, sehr intelligenten Menschen, arbeiten auf diese Protokolle über Jahre hinweg, haben Sie einige Dinge falsch. Es gibt allen Grund zu glauben, dass Sie ich die Arbeit auf diese Art von Sachen auf unserem eigenen Willen machen große Fehler. Die grundlegende Verschlüsselungs-algorithmen sind in Ordnung. Sie sind nicht gebrochen. Aber die Protokolle sind.

    Also, wenn Sie nicht studiert und vollkommen verstanden, alle details des SSL, warum es Sie gibt und wie Sie schief gegangen, in einigen Fällen, dann ist es fast sicher, dass jedes Protokoll, das Sie entwickeln, wird schrecklich sein.

    Nun zu Frage (2). Es gibt zwei Probleme mit diesem. (a) Diffie-Hellman ist nicht entworfen, um die Art von Sicherheit, die Sie wahrscheinlich brauchen werden; und (b) ich glaube nicht, dass Sie eingeführt haben, DH richtig.

    2.a:

    Diffie-Hellman Key exchange, wenn richtig gemacht, sicher ist für den Schlüsselaustausch, aber es tut nichts für die Authentifizierung. Deshalb ist die Frage "ist es sicher" ist oft die falsche Frage. Es ist sicher für einige Zwecke, aber Massiv unsicher für andere, da es nicht für alle anderen Zwecke.

    Als Josh3737 wies darauf hin, es gibt keine Möglichkeit für den client und den server zu wissen, dass Sie sprechen, um die richtige Partei. Wenn Sam ist der server, und Charlie ist der Client, es gibt nichts, hält Mallory von der Einrichtung Ihre eigene server tarnt sich als Sam. Also Cathy gehen kann, durch Austausch der Schlüssel mit Mallory, weil Sie denkt, Sie redet mit Sam. Mallory kann so tun, als sein Charlie, wenn im Gespräch mit Sam.

    Einmal auf diese Weise eingerichtet, Mallory handeln können als ein Mensch In Der Mitte zwischen Sam und Charlie. Wenn Charlie sendet Daten zum Zwecke der Sam, Mallory entschlüsselt es unter Verwendung der gemeinsamen Schlüssel zwischen C und M, es zu Lesen (und möglicherweise ändern), und dann erneut verschlüsseln die den gemeinsamen Schlüssel zwischen M und S und senden Sie dieses ab S.

    Lösen die Authentifizierung problem, Sie brauchen eine Art von Public-Key-Infrastruktur (PKI) und diese sind wirklich ein Schmerz. Das system der Zertifizierungsstellen und solche, die wir mit SSL/TLS ist mit Problemen behaftet, aber es bleibt das beste system gibt.

    2.b:

    Einen öffentlichen 512-bit-Modul zusammen mit dem 512-bit private Schlüssel sind nicht stark genug. DH-Schlüssel müssen größer werden. Ich würde nicht gehen mit etwas weniger als 2048 bit. Sie könnten Weg mit 1024 bit sind Sie nicht besorgt, dass jemand in der Lage zu brechen heute die Geheimnisse von fünf Jahren.

    Du gar nicht genug Informationen geben, wie Sie Ihre Primzahlen ausgewählt wurden. Nicht jede Primzahl funktioniert. Sie benötigen, um ein "safe prime" für Ihre E-Modul, ansonsten gibt es ein Tastenkürzel für einen Angreifer zum berechnen des diskreten Logarithmus.

    • Ausgezeichnete Informationen. Danke!
    • Ich dachte eigentlich, dass DH über HTTPS/TLS kann die Arbeit ziemlich gut... Meine Bedenken sind potentiell korrupt CAs, und dass die Kombination von DH mit einem authentifizierten Kanal könnte zumindest sehr interessant... vielen Dank für Ihre Beratung auf Modul - /Schlüssel-Längen, aber meine größere Sorge wäre, wie nuch Zeit, die es dauern kann, bis ein browser zur Berechnung des gemeinsamen geheimen Schlüssel (sagen wir auf einer typischen smart-phone) in JS.
    InformationsquelleAutor Jeffrey Goldberg
  3. 0

    Wenn Sie möchten, zu bekommen, um die SSL-cert und man in the middle problem, Sie können die bitcoin-blockchain. (Oder ein altcoin blockchain.)

    Der Riesige Nachteil: der Kunde hat entweder download oder aufrechtzuerhalten eine gesamte Datei von der blockchain.

    Gibt es zwei öffentliche/private Schlüsselpaare:

    CERTpublic CERTprivate

    CLIENTpublic CLIENTprivate

    NAMEN-REGISTRIERUNG:

    Server -> CERTpublic and name_to_register -> Bitcoin Blockchain

    AUTHENTIFIZIERTE VERBINDUNG:

    Client <- CERTpublic <- Bitcoin Blockchain
Client -> CERTpublic(CLIENTpublic) -> Server or Adversary
Client <- No_response_or_incorrect <- Adversary 
Client <- CLIENTpublic(CERTprivate(content)) <- Server
    InformationsquelleAutor daftuser
Schreibe einen Kommentar