Public Key Cryptography: How It Uses Symmetric Encryption

Public key cryptography, also known as asymmetric cryptography, solves the problem of securely sharing encryption keys over an insecure channel. However, asymmetric encryption is computationally slow, so in practice it is almost always combined with symmetric encryption to protect the actual data. This guide explains how the two work together in a typical secure communication (like HTTPS or email encryption) and walks you through the process step by step.

What You’ll Need

A basic understanding of encryption concepts (plaintext, ciphertext, keys).
Familiarity with the idea of public and private keys (even if you haven’t used them).
No special software is required—this is a conceptual guide.

Step-by-Step

Understand the two types of encryption. Symmetric encryption uses the same key to encrypt and decrypt data. It is very fast and suitable for large amounts of data. Asymmetric encryption uses a public key to encrypt and a private key to decrypt (or vice versa). It is slow but solves the key distribution problem.
Recognize the problem with symmetric encryption alone. If two parties want to communicate securely using symmetric encryption, they must first share the secret key. Sending that key over an insecure channel risks interception. Asymmetric encryption provides a way to exchange that key securely.
Generate a key pair. In public key cryptography, each party generates a pair of keys: a public key (which can be shared openly) and a private key (kept secret). The public key is used for encryption, and the private key is used for decryption.
Exchange public keys. The sender (Alice) and receiver (Bob) exchange their public keys over any channel—even an insecure one. An attacker can see these keys, but that doesn’t compromise security because the private keys are never shared.
Generate a symmetric session key. When Alice wants to send a large amount of data to Bob, she first generates a random symmetric key (often called a session key). This key will be used only for this one communication session, making it more secure.
Encrypt the data with the symmetric key. Alice encrypts the actual data (the message, file, or stream) using the symmetric session key with a fast symmetric algorithm like AES. This step is fast even for large data.
Encrypt the symmetric key with Bob’s public key. Alice then takes the session key itself and encrypts it using Bob’s public key. This is the crucial hybrid step: the slow asymmetric encryption is applied only to the small key, not the entire data.
Send both to Bob. Alice sends the encrypted data and the encrypted session key to Bob. Even if an attacker intercepts both, they cannot decrypt the session key without Bob’s private key, and they cannot decrypt the data without the session key.
Bob decrypts the session key. Bob uses his private key to decrypt the session key. This works because only his private key can reverse the encryption done with his public key.
Bob decrypts the data. Bob now has the session key and uses it to decrypt the actual data with the same symmetric algorithm. The communication is complete, and the session key can be discarded.

Common Mistakes

Using asymmetric encryption for the entire message. This is unnecessarily slow and inefficient. The whole point of the hybrid approach is to use asymmetric only for the key.
Reusing the same session key. If a session key is reused, an attacker who compromises one session can decrypt all past and future sessions. Always generate a fresh key for each session.
Sharing the private key. The private key must never be shared. If it is exposed, anyone can decrypt messages intended for you.
Not verifying the public key. If you don’t verify that the public key actually belongs to the intended recipient, a man-in-the-middle attack is possible. Use certificates or out-of-band verification.

Tips

Use established protocols. In practice, you don’t implement this yourself. Use protocols like TLS (for HTTPS) or PGP (for email) that handle the details correctly.
Use strong symmetric algorithms. AES-256 is a solid choice for the symmetric part. For asymmetric, RSA-2048 or ECC (like Curve25519) are common.
Keep session keys ephemeral. Generate a new session key for every session and destroy it after use. This limits the damage if one key is compromised.
Use forward secrecy. Prefer protocols that use ephemeral key exchange (e.g., ECDHE) so that even if the long-term private key is compromised, past sessions remain secure.

Troubleshooting

Decryption fails. This usually means the wrong private key was used, or the public key used for encryption doesn’t match the private key. Double-check that you have the correct key pair.
Data is corrupted. If the encrypted data arrives corrupted, the symmetric decryption will produce garbage. Ensure the data integrity is checked (e.g., using a MAC or authenticated encryption).
Performance is slow. If you notice slowness, you might be using asymmetric encryption on large data. Check your implementation—it should only encrypt the key with asymmetric.
Man-in-the-middle attack suspected. If you suspect an attacker is intercepting and substituting public keys, verify the key fingerprint through a separate channel (like a phone call) or use a trusted certificate authority.

Frequently Asked Questions

Why not just use symmetric encryption for everything?

Symmetric encryption is fast, but it requires both parties to share the same key beforehand. Public key cryptography solves the key distribution problem without needing a secure channel.

Is public key cryptography slower than symmetric?

Yes, asymmetric algorithms like RSA are computationally much slower than symmetric ones like AES. That’s why the hybrid approach is used: asymmetric for the key, symmetric for the data.

Can I use the same key pair for both encryption and signing?

Technically yes, but it’s not recommended. Using separate keys for encryption and signing limits the risk if one is compromised.

What is forward secrecy?

Forward secrecy means that if the long-term private key is compromised, past session keys are still safe. It is achieved by using ephemeral key exchange (like ECDHE) so that each session key is independent.

How do I know a public key is authentic?

You can verify the key’s fingerprint through a separate trusted channel, or rely on a certificate authority (CA) that vouches for the key’s owner.

Does this apply to everyday internet use?

Yes, every time you visit a website using HTTPS, your browser and the server use this exact hybrid approach to establish a secure connection.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →