at the moment I am working on a chat application, where more than two clients can communicate at the same time.

I just got started with the encryption so please be bear with me.

My goal is to implement end-to-end-encryption so I've done some research on that and I found about Diffie–Hellman key exchange. I have a brief idea how it works, also plenty of questions.

On wikipedia it says that it works as following:

  1. We decide on a big prime number, we'll call it P.
  2. g has to be a primitive prime root of P.
  3. Each client picks an arbitrarily private key which follows this condition: 1<= Private_key <= P
  4. They send their private keys which are generated as following: (g^private_key) mod Pover the server
  5. the secret shared key is (User2PublicKey^User1PrivateKey) mod Pand vice versa(User1PublicKey^User2PrivateKey) mod P

My questions to you are:

  • Does this work on a multi-client chat? I had some attempts on paper to emulate a connection for three clients and I couldn't get the same shared key. If so could you provide me an example for that please?
  • I know it may sound silly, but P, g and the keys are just integers? Like P could be 139, g 37 and so on?
  • Instead of encrypting the messages with the recipient's public key, couldn't I use the secret shared key for that? To avoid encrypting the message for each client connected.
  • P and g could be generated on the server side?
  • Could anybody provide me an example of implementing this in Java?
  • Beside all your questions: Don't write an encryption angorithm yourself. That's never a gold Idea! – Samuel Philipp Jun 16 '19 at 21:44
  • 2
    1. You are unqualified to implement end to end encryption people might rely on for protecting real secrets. People will get hurt. 2. Do not under any circumstances try to combine cryptographic primitives into a protocol. It will be insecure. Use libsodium, it has a bunch of Java bindings. libsodium.gitbook.io/doc/bindings_for_other_languages – Z.T. Jun 16 '19 at 22:19
  • For completeness I'll add that in 2019, nobody would use FFDHE for something new. Google Chrome removed support for FFDHE (in TLS) and it kinda went extinct. For anything new, everyone would use X25519. If you don't know that, you are definitely unqualified to work on crypto. A "can do" attitude is the opposite of what you want from security and safety-critical engineers. It is quite easy to create something that appears to work and the creators see no flaws in it, but is actually unsafe and/or insecure. You can also read how Signal Protocol works and maybe understand how far you are from it. – Z.T. Jun 16 '19 at 22:29
  • If your main goal is a chat application, why don't you use any libraries for encryption? – mentallurg Jun 17 '19 at 0:47
  • Im doing this for a personal project, just to see if I can do it. Its not meant for a real world app. – Terchila Marian Jun 17 '19 at 0:52

You should never write an implementation to an existing algorithm or design an algorithm. The algorithm should be picked up from a book and implementation from a library.

Keeping the above points in mind, remember that Diffie Hellman is vulnerable to MITM attacks as there is no authentication factor involved in the protocol. For confidentiality, I would recommend using SSL.

Generate a self-signed certificate for Entity B. Entity A will have a copy of the certificate and would trust it. Entity B is authenticated. Now for the authentication of A, you can simply have a pre-shared secret which A will represent and B will verify.

You can refer the docs for DKE implementation in node.js - https://nodejs.org/api/crypto.html#crypto_diffiehellman_computesecret_otherpublickey_inputencoding_outputencoding

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.