Diffie-Hellman Key Exchange via REST
Diffie–Hellman (DH) protocol is a method of asymmetric exchange of the cryptographic keys for a group of two or more participants, developed in 1976 by cryptographers Ralph Merkle, Whitfield Diffie and Martin Hellman. In contrast to the symmetric key exchange, the Diffie–Hellman protocol eliminates the direct transfer of the shared secret between the participants so that each participant computes a shared secret with his own private-public key pair. The Diffie–Hellman protocol is based on a one-way function of the form
where
- A is the user’s public key
- a is the user’s private key
- P = 2Q + 1 is modulus such that at least 2048 bits safe-prime because Q is also prime
- G is generator such that G is primitive root modulo P
We say that G is primitive root modulo P if for each 1 ≤ a ≤ P − 1 the A = G^a mod P is unique and belongs to the set {1, 2, . . . , P − 1}. The period of such cyclic group Z(p) is P − 1 then.
Thus, the safety of the Diffie–Hellman protocol is based on the discrete logarithm problem which is unsolvable in polynomial time if the constants G and P are chosen correctly. Graphically the flow of the Diffie–Hellman protocol can be expressed through the analogy with mixing paints as the picture below shows
In contrast to the Diffie–Hellman based on discrete logarithm problem, there is an Elliptic Curve Diffie–Hellman key exchange which is based on the elliptic curve discrete logarithm problem. Although, the idea is quite same, the difference only in that Elliptic Curve Diffie–Hellman ensures the same safety as discrete logarithm Diffie–Hellman with lower number of bits of the prime modulus P.
For instance, 521 bit modulus P used in Elliptic Curve Diffie–Hellman
is equally safe as 2048 bit modulus in discrete logarithm Diffie–Hellman. To summarize, the flow of Diffie–Hellman key exchange is as follows.
Given 2048 bits public prime modulus P and generator G such that G is primitive root modulo P then
- Alice chooses her secret a
- Alice sends to Bob her public key A = G^a mod P
- Bob chooses his secret b
- Bob sends to Alice his public key B = G^b mod P
- Alice computes common secret s = B^a mod P
- Bob computes common secret s = A^b mod P
- Alice and Bob have arrived to the same value that is common secret s:
Diffie-Hellman key exchange implementation via REST
Although, the idea of Diffie–Hellman key exchange looks quite simple, some remarks on the concrete implementation should be added. Firstly, it is necessary to implement the mechanism of key exchange request between two or more parties. As it discussed previously, each user has his own private-public key pair so that in order to perform request between parties it should be implemented dedicated REST web–service endpoint. For instance, the
POST: api/key-exchange-requests which takes the request body of the form
So, request sender generates on the client side a key pair, keeps private on in the file system and shares the public in request to receiver. Therefore, the second party has received the key exchange request. In order to display all the key exchange requests awaiting the confirmation of decline decisions, it is worth to implement another REST endpoint such that GET: api/key-exchange-requests so that requested party will have the list of requests to proceed. This endpoint may return the data structure like follows
Finally, requested party should be able to confirm or decline the key exchange request, the DELETE: api/key-exchange-requests endpoint should be implemented then. The server is able to fetch the request thanks to the body endpoint takes
Therefore, an identifier of awaiting request is passed to the server among with boolean value indicating the confirmation. Under the roof of this operation are also generation of private-public keys pair for the requested party and generation of common secret stored in client’s file system. As result, the initial request sender receives a public key as confirmation from requested party. Requested side may get all his public keys via the REST web–service
using the resource GET: api/public-keys
Now requested participant is able to derive the common secret. In order to provide an example, a simple command line interface is implemented. We have used an Elliptic Curve Diffie–Hellman implementation ECDiffieHellmanCng Class from the namespace System.Security.Cryptography of the .NET base class library. The P-256 curve is used.
More precisely, the following CLI commands are implemented
- MangoAPI.DiffieHellmanConsole login SENDER_EMAIL SENDER_PASSWORD
- MangoAPI.DiffieHellmanConsole key-exchange RECEIVER_ID
- MangoAPI.DiffieHellmanConsole key-exchange-requests
- MangoAPI.DiffieHellmanConsole confirm-key-exchange REQUEST_ID
- MangoAPI.DiffieHellmanConsole print-public-keys
- MangoAPI.DiffieHellmanConsole create-common-secret RECEIVER_ID
Commands are self-explanatory, therefore we skip the detailed documentation on them. An example of console output straightforward
In order to repeat the outputs on the screenshot the user may reference to the resources
- API: https://back.mangomessenger.company/swagger
- Source: https://github.com/MangoInstantMessenger/MangoMessengerAPI
- Article: https://github.com/kolosovpetro/DiffieHellmanKeyExchange
Finally, both test accounts reached the same base 64 common secret
Thanks for reading!
