Client-side encryption over HTTP using Diffie-Hellman Key and AES key exchange

Question

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

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

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

  • Client and server start with a shared public key with 512 bit pK

  • The client generates a 512-bit simple private key kC and sends powMod (3, kC, pK)

  • The server generates a 512-bit simple secret key kS and sends powMod (3, kS, pK)

  • Client and server use powMod (response, privatekey, pK) as a shared key

• Step 2: Communication

  • Before the client sends the data, it will be encrypted using a shared key using the Stanford cryptographic library library (256-bit AES authentication, HMAC, PBKDF2 password gain and CCM authentication.)

  • After the server decrypts the data using the shared key, it generates a new 512-bit simple private key and sends it as an encrypted SJCL response.

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

Now I have a few questions.

How secure is this system compared to HTTPS or other algorithms? What are the weakest points of such a system?

Regarding security / usability, would it be better to use 1024-bit keys for increased security? Are the HMAC / PBKDF2 / CCM options overloaded? Is it worth modulating a shared key? Thanks for reading!

Answer 1

I have seen such questions as before - this is completely unsafe for a number of reasons , the main one being the fact that JavaScript is not possible to verify the authenticity of a server key.

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

Answer 2

Your system is very unsafe, but I'm not trying to dissuade you or anyone else from playing with such things. You must go on. But it’s very important that you consider what you are creating in order to be a “toy” system that should never be viewed or advertised as “safe”.

Let me break the security question into two parts.

• How secure is key exchange?
• How secure is the encryption you use when you have a shared key?

Let me answer (2) first, as this will be the simplest. It will be terribly uncertain if you are not smarter than all the people who have worked and studied TLS over the years. TLS prior to version 1.2 (using multiple sites) is vulnerable to Chosen Ciphertext Attacks (CCA) in principle and to a BEAST attack in practice, depending on the choice of encrypted suit. And SSL 2.0 is more severely compromised.

The fact is that very smart people working on these protocols for many years were wrong. There is every reason to believe that I am working on these things myself, I will make huge mistakes. Basic encryption algorithms are in order. They are not broken. But the protocols.

So, if you have not yet studied and completely understood all the details of SSL, why they were there and how they were mistaken in some cases, then any protocol that you develop will almost certainly be terrible.

Now to the question (2). There are two problems with this. (a) Diffie-Hellman is not intended to provide the types of security that you probably need; and (b) I don’t think you implemented DH correctly.

2.a:

Key exchange Diffie-Hellman Key, when done correctly, is safe for key exchange, but it does nothing for authentication. This is why the question “safe” is often the wrong question. It is safe for some purposes, but largely unsafe for others, as it is not intended for other purposes.

As Josh3737 pointed out, the client and server do not know that they are talking to the right side. If Sam is the server and Charlie is the Client, there is nothing that prevented Mallory from creating his own server, which masquerades as Sam. So, Katie can exchange the keys with Mallory, thinking that she is talking with Sam. Mallory can pretend to be Charlie when talking to Sam.

Once he's set up that way, Mallory can act as the man in the middle between Sam and Charlie. When Charlie sends the data intended for Sam, Mallory decrypts it using the shared key between C and M, reads it (and possibly changes it), and then re-encrypts it with the shared key between M and S and sends it to S.

To solve the authentication problem, you need some kind of public key infrastructure (PKI), and this is really a pain. The System of Certification Authorities and such that with SSL / TLS is fraught with problems, but it remains the best system there.

2b:

A 512-bit public module along with 512-bit secret keys is not strong enough. DH keys should be larger. I would not go with something less than 2048 bits. You can leave with 1024 bits, you don’t worry that someone will be able to break secrets today in five years.

You did not provide enough information about how your primes were chosen. Not every prime minister will work. You need to use the "safe bar" for your module, otherwise there are shortcuts available for the attacker to calculate the discrete logarithm.

Answer 3

If you want to get around the SSL certificate and the person in the middle problem, you can use bitcoin blockchain. (Or alkane blockchain.)

Huge caveat: the client must either download or save the entire blockchain file.

There are two pairs of public / private keys:

Certpublic certprivate

CLIENTpublic CLIENTprivate

REGISTRATION NAME:

Server -> CERTpublic and name_to_register -> Bitcoin Blockchain 

AUTHENTIC CONNECTION:

 Client <- CERTpublic <- Bitcoin Blockchain Client -> CERTpublic(CLIENTpublic) -> Server or Adversary Client <- No_response_or_incorrect <- Adversary Client <- CLIENTpublic(CERTprivate(content)) <- Server