1

Diffie Hellman is a key exchange algorithm where client and server both generate public and private key, exchange their public key and combine this key with his own private key to generate same secret key.

But, here is a confusion in the implementation. Here is the code...

const crypto = require('crypto');
const express = require('express');
const app = express();

// Generate server's keys...
const server = crypto.createDiffieHellman(139);
const serverKey = server.generateKeys();

// Generate client's keys...
const client = crypto.createDiffieHellman(server.getPrime(), server.getGenerator());
const clientKey = client.generateKeys();

// Exchange and generate the secret...
const serverSecret = server.computeSecret(clientKey);
const clientSecret = client.computeSecret(serverKey);  

First of all, server create an instance of DiffieHellman class to generate key. But, client need server's prime (.getPrime()) and Generator (.getGenerator()) to generate another instance of DiffieHellman class to generate key.

So, server need to pass the value of server.getPrime() and server.getGenerator() to the client. What happen if any middle-man-attack rises in this time? Because, if somehow hacker get this two things then they can also generate same secret key. (-_-)

Any solution? Think this system without TLS.

1 Answer 1

2

You are assuming that generateKeys is a deterministic operation so that a attacker knowing the DH parameters will generate exactly the same keys. But this is a wrong assumption. The attacker will end up with different keys even when using the same DH parameters since randomness is involved when generating the keys and the attacker cannot replicate the randomness used by the client.

4
  • But, if attacker generate same key and then pass it to the server or client to computeSecret then how i confidentially say that key is not coming from attacker? Commented Aug 18, 2020 at 17:41
  • @RAKTIMBANERJEE: "... if attacker generate same key ..." - this is like asking what happens if a asteroid destroys the earth. Yes, we are not prepared for this since this is very unlikely. Probably more unlikely than the asteroid. The point of good random data is that they cannot be guessed nor accidentally recreated and thus the attacker is not able to create the same keys. Commented Aug 18, 2020 at 18:29
  • Actually, I want to talk about public key. I want to mean that if attacker know p and g then he can generate public key (not secret Key). Now, server is waiting for client side public key but what happen if the public key is coming from attacker. Because public key can be anything. I want to say if attacker send me his own key which is generated using shared p and g. Commented Aug 18, 2020 at 19:24
  • @RAKTIMBANERJEE: "... if attacker know p and g then he can generate public key (not secret Key)" - DH does not work this way. Both the public and the private key of a peer depend on a random secret chosen by each peer. I recommend that you make yourself familiar first with how DH works, for example by reading the relevant part on Wikipedia. Commented Aug 19, 2020 at 2:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .