Let's say I've got two people that are trying to talk in a public channel $A$ and $B$ and they want to preserve their confidentiality and integrity.

Which cryptographic algorithm would they want to use? Symmetric, or public key based? Also, what type of algorithm suites best and in what key size?

In my understanding, given the fact that the channel is public – and therefore considered unprotected – they will have to use public key first and send a symmetric key after that, thus securing the channel. Regarding key exchange they could use Diffie Hellman or RSA, and on symmetric key MAC.

Is this correct? Could they do it easier? Is there a safer way?


1 Answer 1


Which cryptographic algorithm would they want to use?

That will really depend on the situation. To select the algorithms one should ask himself (at least) the following questions:
Which standards do you trust? Which standard do you have to use? What computations can you afford?

Symmetric, or public key based?

It again depends on the situation. Usually you'll use a combination of both, however there are valid use-cases for using only public key cryptography (usually extremely short messages) and for using only symmetric cryptography, usually when performance is a constraint or when a shared secret has already been established (i.e. with embedded devices or in a session resumption scenario).

Also what type of algorithm suites best and in what key size?

The algorithms really depend on the situation given. Generally however, 128 - 256 bit symmetric encryption, 256 - 512 bit hash functions, 256 - 512 bit elliptic curves and / or 2048 - 4096 bit classical asymmetric cryptography (RSA, DSA, ...) is in use.

Considering your third paragraph:
In a nutshell, you're right. You first negotiate a symmetric key using asymmetric cryptography (RSA or (EC)DH) and then use symmetric crypto to protect your payload. What you described is basically opportunistic encryption, because neither party takes measures to ensure the authenticity of the other party. This means a man-in-the-middle attack would certainly be possible and thus an active attacker could break the scheme.

Is there a safer way?

There is: Transport Layer Security (TLS).
TLS is the standard solution for secure real-time data transport and even has some nice security proofs. TLS can take care of all the situations you can possibly encounter: You can use a pre-shared key, you can authenticate against a server with a password (via SRP), you can use a certificate (or just a public key) for only one or both parties and even is widely deployed with famous libraries being OpenSSL, LibreSSL, BoringSSL, ....

  • $\begingroup$ Thanks for taking the time to answer. Spot on answers , although one thing comes to mind. If they use MAC as symmetric cryptography , wouldn't that elliminate the M-I-T-M attacks and preserve Integrity and Authenticity of the Message? On the other hand they could be vulnerable to Replay attacks. $\endgroup$
    – Jamesgr
    Jan 22, 2016 at 11:00
  • $\begingroup$ @Jamesgr, Replay attacks are mitigated by authenticated counters (which lead to message rejection if they're too small). MITM attacks apply mainly to the key-exchange phase where you can't be assured with whom you exchange your key - with the intended party or with the intended party via a MITM (i.e. with the MITM). Indeed, the MAC protects the message from MITM attacks. $\endgroup$
    – SEJPM
    Jan 22, 2016 at 13:55
  • $\begingroup$ Since it is public key, anyone can get it. So does an eavesdropper. Then he can also decrypt the symmetric key from the initial handshake. And then all subsequent communication is no secret. Is that an issue? $\endgroup$ Sep 5, 2018 at 2:51
  • $\begingroup$ @smwikipedia the public key is no help in decrypting the symmetric key. That's the entire point of asymmetric encryption after all. $\endgroup$
    – SEJPM
    Sep 5, 2018 at 6:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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