I was wondering the difference in term of Security, Computational cost and Network overhead between the use of :

  • A Key-Exchange Algorithm (e.g. Diffie–Hellman) to set up a symmetric key.
  • The generation by the Client of a symmetric key and the send it ciphered (e.g. RSA) to the Server.

Indeed, I'm designing a protocol that only need one request to a Server and one answer from the Server (through a Proxy). I consequently have to choose between these 2 protocols :

  1. Diffie–Hellman Algorithm (with asymmetric encryption because of the proxy) followed by symmetric encryption of the query and the answer
  2. A key generated by the client send ciphered (asymmetric encryption) together with the query and an answer by the server ciphered (symmetric encryption) by the key received previously from the client.

If I use the protocol 1., I have the current situation :

  • Asymmetric Encryption : 1 operation (Key establishment)
  • Asymmetric Decryption : 1 operation (Key establishment)
  • Symmetric Encryption : 2 operations (Request+Answer)
  • Symmetric Decryption : 2 operations (Request+Answer)
  • Packet exchange : 4

If I use the protocol 2., I have the current situation :

  • Asymmetric Encryption : 1 operation (Key establishment)
  • Asymmetric Decryption : 1 operation (Key establishment)
  • Symmetric Encryption : 1 operation (Request+Answer)
  • Symmetric Decryption : 1 operation (Request+Answer)
  • Packet exchange : 2

The protocol 2. seems to be more powerful than the protocol 1. but when I looked on the Internet, people usually talk about the first protocole (1.) I am wondering why ? Is the second one not secure ?

Thanks for you answer !

  • Diffie-Hellman is not interactive, so it doesn't cost a round trip (when performed using the long-term key). If you want forward secrecy for the query, not just the response, you'll need on extra round trip to obtain the ephemeral key. – CodesInChaos Feb 10 '14 at 10:13
  • Your protocol descriptions are pretty vague. You should specify which computations each side performs and which messages it sends. I don't see why you have different numbers of opertations/packet exchange for your two different protocols. – CodesInChaos Feb 10 '14 at 10:15
  • First protocol : 1° (C->S) {g^X}_pkS ; 2° (S->C) {g^Y}_pkS ; 3° (S->C) {Query}_K ; 4° (C->S) {Answer}_K Second protocol : 1° (C->S) {Query,K}_pkS ; 2° (S->C) {Answer}_K – aztitep Feb 10 '14 at 12:16

Diffie-Hellman and RSA-based key exchange have the same dynamics and similar costs. In both cases:

  • System A must send (possibly publish way in advance) a public element (RSA public key with RSA, ga for DH).
  • System B generates some values which culminate in a symmetric key K and an element to send to A (with RSA, B generates K randomly and encrypts it with A's public key; with DH B generates gb and computes K = gab).
  • If B has a confidential message to send to A, then he can encrypt it with K and send it right away, along with the element from the previous step.

Indeed, one can see DH as a kind of asymmetric encryption where the sender does not get to choose the data he encrypts; instead, he learns the "shared secret" during processing, and that is good enough for key exchange.

(From your description, you seem to imagine that obtaining the DH shared secret would somehow imply another network round-trip; that is not true.)

DH is popular in protocols for a variety of reasons. Historically, it was promoted by the US government for US Federal usages, because RSA was patented and the US government had no wish to pay. Nowadays, the elliptic curve variant of DH is appreciated for its good performance (faster than RSA, and using smaller messages, though there are details).

| improve this answer | |
  • I don't really understand why DH shared secret would not imply another network round-trip. Because here, in my both protocols a preliminary step implies to retrieve the public key of the server (pkS). – aztitep Feb 10 '14 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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