What is Asymmetric Encryption — Public Key Cryptography Explained

Key Takeaways

Asymmetric encryption uses two mathematically linked keys — public (shared freely) and private (kept secret)

It solves the key distribution problem: you can encrypt for someone without ever sharing a secret with them

Too slow for bulk data — used to exchange symmetric keys (TLS handshake) or create digital signatures, not to encrypt payloads

RSA and ECC are the two dominant algorithms — ECC provides equivalent security with much smaller keys

Asymmetric encryption (public key cryptography) uses a pair of mathematically related keys: a public key that anyone can have, and a private key that only the owner possesses. Data encrypted with the public key can only be decrypted with the corresponding private key — and vice versa. This solves the fundamental problem of symmetric encryption: how do two parties establish a shared secret without a pre-existing secure channel?

Why it matters

Solves key distribution — symmetric encryption requires both parties to share the same key securely. Asymmetric encryption eliminates this: you publish your public key openly, and anyone can send you encrypted data that only you can decrypt.
Enables digital signatures — signing with a private key produces a signature that anyone with the public key can verify. This proves authenticity and integrity without revealing the private key.
Foundation of TLS — every HTTPS connection uses asymmetric cryptography during the handshake to authenticate the server and establish symmetric session keys. Without it, secure web communication wouldn’t exist.
Certificate-based identity — X.509 certificates bind a public key to an identity. The entire PKI ecosystem is built on asymmetric cryptography.
Performance trade-off — asymmetric operations are 100-1000x slower than symmetric. This is why TLS uses asymmetric crypto only for the handshake, then switches to symmetric (AES) for data transfer.

How it works

Key generation — a mathematical algorithm generates a key pair. The private key is a secret value; the public key is derived from it. You cannot feasibly compute the private key from the public key.
Encryption — sender encrypts plaintext with the recipient’s public key. Only the recipient’s private key can decrypt it.
Decryption — recipient uses their private key to recover the plaintext.
Signing — signer creates a hash of the message, then encrypts the hash with their private key (producing the signature).
Verification — verifier decrypts the signature with the signer’s public key, computes their own hash of the message, and compares. Match = authentic and unmodified.

The math (simplified):

RSA: based on the difficulty of factoring large prime products (n = p × q)
ECC: based on the difficulty of the elliptic curve discrete logarithm problem
Both rely on mathematical problems that are easy in one direction but computationally infeasible to reverse.

In real systems

TLS handshake (key exchange):

Client → Server: ClientHello (supported algorithms)
Server → Client: Certificate (containing server's public key)
# Client uses server's public key to verify the handshake
# ECDHE key exchange derives shared symmetric keys
# All subsequent data encrypted with AES (symmetric)

SSH key authentication:

# Generate key pair
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
# Public key → deployed to server (~/.ssh/authorized_keys)
# Private key → stays on client, never transmitted
# Authentication: client signs a challenge with private key, server verifies with public key

GPG/PGP email encryption:

# Encrypt a file for a recipient
gpg --encrypt --recipient recipient@example.com secret.pdf
# Uses recipient's public key — only their private key can decrypt

# Sign a file
gpg --sign --armor message.txt
# Uses your private key — anyone with your public key can verify

Where it breaks

Private key exposure — if the private key is compromised, an attacker can decrypt all past messages encrypted to that key (unless forward secrecy was used) and impersonate the key owner. Unlike passwords, you can’t just “change” a private key — you must revoke the associated certificate and re-establish trust with a new key pair.

Performance misuse — encrypting large files directly with RSA is extremely slow and has size limitations (RSA can only encrypt data smaller than the key size minus padding). The correct pattern: generate a random symmetric key, encrypt the data with AES, then encrypt only the symmetric key with RSA (hybrid encryption). Every modern system does this, but custom implementations sometimes get it wrong.

Key size confusion — RSA 2048-bit and ECC P-256 provide roughly equivalent security (~128-bit symmetric equivalent). But RSA 2048 keys are 256 bytes while ECC P-256 keys are 32 bytes. Choosing RSA where ECC would suffice wastes bandwidth and CPU — especially in constrained environments (IoT, mobile) and high-volume systems (TLS termination at scale).

Operational insight

Asymmetric encryption doesn’t encrypt your data — it encrypts the keys that encrypt your data. In every practical system (TLS, S/MIME, PGP, disk encryption), asymmetric crypto is used only for key exchange or digital signatures. The actual data protection is always symmetric (AES, ChaCha20). Understanding this layering is critical: when someone says “we use RSA-2048 encryption,” they mean RSA protects the key exchange — AES-256 protects the data. If you’re evaluating cryptographic strength, you need to assess both layers, not just the asymmetric algorithm in the certificate.

Key Takeaways

Why it matters

How it works

In real systems

Where it breaks

Operational insight

Related topics

Ready to Secure Your Enterprise?

Stay ahead on cryptography & PKI