SSL uses both asymmetric cryptography and symmetric cryptography.

Why can't it, or why doesn't it, just use one of them?

  • 11
    It is unclear what your are asking but my guess is that you mean SSL/TLS instead of SSI and mean asymmetric (public key) vs. symmetric ("secret key") cryptography. Still it is unclear what you are trying to ask with "why can't employ one of them?". Also, how does the tag passwords you used apply to this question? If this is about SSL/TLS you might actually find your answer in How does SSL/TLS work?. Commented Mar 19, 2017 at 5:35
  • 10
    Did you make research on what you want to comprehend ? because the question suggests the opposite.
    – elsadek
    Commented Mar 19, 2017 at 6:06
  • Asymmetric crypto is used just to encrypt the "session key", this one is a symmetric key which is, then, used to ecrypt/decrypt the communication between the server and client.
    – elsadek
    Commented Mar 19, 2017 at 6:52
  • 2
    SSL is not just "considered" to employ both of those. It does employ both of those. Commented Mar 19, 2017 at 22:32
  • 1
    @MichaelKjörling So does TLS. It has its own key agreement protocol, and that is what is used.
    – user207421
    Commented Mar 20, 2017 at 11:09

2 Answers 2


Symmetric cryptography cannot be used for exchanging secrets between machines that had never communicated before, but asymmetric cryptography is limited to encrypting very small data (the size of the key) and is extremely slow when used to encrypt larger blocks. That's why all practical cryptography scheme uses both.

  • Actually, you can use symmetric cryptography to do that; however that requires a trusted middle agent to exchange trust. This is sort of like a CA, however (unlike) a CA, it needs to be an active participant.
    – poncho
    Commented Mar 19, 2017 at 21:24
  • 1
    @poncho Symmetric key crypto requires unique keys per session, especially if you would use it without prior asymmetric crypto to initiate a secure connection. I have no idea how you would implement a trusted middle part that would correctly manage and handle out the symmetric keys without risking impersonation
    – BlueCacti
    Commented Mar 19, 2017 at 22:17
  • 1
    [Waited to long to edit last comment] Pure symmetric key communications are often only done between parties who know each other and who have an already trusted method of sharing the symmetric keys amongst each other, preferably using a method where each party can identify/authenticate and authorize the other.
    – BlueCacti
    Commented Mar 19, 2017 at 22:24
  • @GroundZero: the Kerberos model; Alice shares a secret key with the central authority, Bob shares a secret key with the central authority; it all works from there. Yes, asymmetric crypto really is considerably more convenient, however, there are alternatives...
    – poncho
    Commented Mar 20, 2017 at 3:13
  • @poncho Then said central authority gets compromised. Note that Kerberos solves the problem of one node authenticating itself to another; it doesn't attempt to solve the problem of key distribution. Key distribution might possibly be superimposed on top of regular Kerberos, but then you are using it to do something it wasn't intended to do, with all of the caveats that follow.
    – user
    Commented Mar 20, 2017 at 8:28

Just to underline how TLS use this

  1. Asymmetric cryptography :: The client check the certificate (from the server) and use the public key specified into it. It makes some good things (you can learn more on Wikipedia) and then establish a secret key for symmetric encryption.
  2. Symmetric cryptography :: Here, the data is securely exchanged between the client and the server, using the secret key generated previously.

Let's say we want just one of them:

  • Symmetric only : As the Red Telephone, then you have to establish a secure way to share the key
  • Asymmetric only : You need to be really patient, an heavy computational cost, and can be less secure, as it's not using session keys.

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