Search code examples
javascriptnode.jsencryptionaesdiffie-hellman

Client-side encryption over HTTP with Diffie-Hellman Key Exchange and AES


After watching a YouTube video on the Diffie-Hellman Key Exchange, I wanted to try an implementation in JavaScript (Atwood's law).

I sketched up an cipher on Node.js with the following rules:

  • Step 1: Client and server agree on a shared key:

    • Client & server start with a 512bit prime public key pK

    • Client generates a 512bit prime private key kC and sends powMod(3, kC, pK)

    • Server generates a 512bit prime private key kS and sends powMod(3, kS, pK)

    • Client & Server use powMod(response, privatekey, pK) as the shared key

  • Step 2: Communication

    • Before a client sends data it is encrypted with the shared key using the Stanford Javascript Crypto Library (256bit AES, HMAC authentication, PBKDF2 password strengthening, and CCM authenticated-encryption.)

    • Once the server decrypts the data with the shared key, it generates a new 512bit prime private key and sends it as a SJCL encrypted response.

    • The client and server switch to a new shared key using powMod(3, prevSharedKey, newPrivKey)

Now I have a few questions..

How secure would such a system be in comparison with HTTPS or other algorithms? What are the weakest points of such a system?

In terms of security / practicality, would it be better to use 1024 bit keys for stronger security? Are the HMAC/PBKDF2/CCM options overkill? Is it worth modulating the shared key? Thanks for reading!


Solution

  • I've seen questions like this before – this is completely insecure for a number of reasons, foremost of which is the fact that it is impossible for a JavaScript client to verify that the server's key is authentic.

    In a nutshell, without SSL, you are vulnerable to man-in-the-middle attacks. No browser-based JavaScript crypto implementation can overcome this fact.