Asymmetric encryption

The problem it solves

Symmetric encryption has one fundamental limitation: both parties need the same key. Getting that key to the other party securely is the key distribution problem. If you already had a secure channel to send the key, you could have just sent the message that way.

This was an unsolved problem for most of cryptographic history. The answer, discovered independently by researchers in the 1970s, was asymmetric encryption: instead of one shared key, each party has a key pair - a public key and a private key. The two keys are mathematically linked but you cannot derive one from the other in any practical amount of time.

The public key can be given to anyone - posted publicly, included in a certificate, sent over an insecure channel. The private key never leaves its owner. This separation is what makes the whole thing work.

What the two keys do

The key pair serves two distinct purposes depending on which direction you use it:

• Encryption: anyone with the public key can encrypt a message. Only the private key can decrypt it. You publish your public key; anyone who wants to send you something private encrypts it with your public key; only you can read it.
• Signing:the private key can sign a message. Anyone with the public key can verify the signature. This proves the message came from whoever holds the private key, and that it hasn't been modified. This is the reverse direction - private key in, public key to verify.

These are the same key pair used in two different ways. TLS certificates use signing: a Certificate Authority signs a certificate with its private key; your browser verifies it with the CA's public key. Encrypting an email to someone uses the other direction: you encrypt with their public key; only they can decrypt with their private key.

How it works - trapdoor functions

Asymmetric encryption relies on mathematical problems that are easy to compute in one direction but practically impossible to reverse without a specific piece of information - called a trapdoor function.

RSA is based on the difficulty of factoring large numbers. Multiplying two large prime numbers together is fast - even huge primes multiply in milliseconds. But given the result, working out which two primes were multiplied is computationally infeasible for large enough numbers. The public key contains the product; the private key contains the primes. Encrypting uses the product; decrypting requires the primes.

Elliptic curve cryptography (ECC) is based on the difficulty of the elliptic curve discrete logarithm problem - a different hard problem with a similar trapdoor structure. It achieves equivalent security to RSA with much smaller keys: a 256-bit elliptic curve key is roughly equivalent in security to a 3072-bit RSA key. Smaller keys mean faster operations and less data to transmit.

You do not need to understand the mathematics to use these correctly. What matters is knowing which algorithms are current, which are deprecated, and what the key size recommendations are.

RSA vs elliptic curve

RSA is the older standard. Still widely used and well-supported everywhere. For RSA to be considered secure today, you need at least a 2048-bit key; 3072 or 4096 bits is recommended for new systems. Larger keys mean slower operations - RSA-4096 signing is noticeably slower than RSA-2048.

ECDSA (Elliptic Curve Digital Signature Algorithm) and ECDH (Elliptic Curve Diffie-Hellman) are the elliptic curve equivalents for signing and key exchange respectively. A 256-bit elliptic curve key is considered equivalent to RSA-3072, with dramatically faster operations. The most commonly used curve is P-256 (also called prime256v1 or secp256r1), which is what most TLS certificates use when you see "EC" in the certificate details. Curve25519 is increasingly preferred in newer protocols for its stronger security properties and resistance to implementation mistakes.

For new systems, elliptic curve is the right choice. RSA remains fine if you need maximum compatibility with older software.

Diffie-Hellman key exchange

Asymmetric encryption itself is too slow for bulk data - encrypting a large file with RSA is painfully slow compared to AES. The real-world pattern is to use asymmetric cryptography only to establish a shared secret, then switch to symmetric encryption for everything else. This is what Diffie-Hellman key exchange does.

The intuition: imagine mixing paint. If Alice and Bob each start with the same public colour (say, yellow), mix in their own private colour, and then exchange the results, they can both mix in the other's result to arrive at the same final colour - without ever having transmitted their private colour. An observer who sees the exchanged mixtures cannot easily separate them back out to learn the private colours.

In practice, Alice and Bob exchange public keys over an insecure channel, each combines their private key with the other's public key, and both arrive at the same shared secret - which becomes the symmetric key for the session. The shared secret was never transmitted.

How TLS uses both types of encryption

TLS brings both types of encryption together:

1. The server presents its certificate, which contains its public keyand is signed by a Certificate Authority using the CA's private key. Your browser verifies the signature using the CA's public key from its trust store. This proves the server is who it claims to be.
2. Client and server perform an ephemeral Diffie-Hellman key exchange to establish a shared secret. Neither side's long-term private key is used for this - only the ephemeral keys generated for this session.
3. Both sides derive a symmetric session key from that shared secret.
4. All subsequent traffic is encrypted with AES-GCM using that symmetric key. Asymmetric cryptography is done.

The asymmetric part handles authentication and key establishment. The symmetric part handles bulk encryption. Each does what it is fast at.

Where you encounter this as a developer

• TLS certificates- the certificate contains your server's public key. The corresponding private key lives on your server and never leaves it. When you generate a certificate signing request (CSR), you are generating a key pair and asking a CA to sign the public half.
• SSH keys - ssh-keygen generates a key pair. You put the public key on the server (~/.ssh/authorized_keys); you keep the private key locally. Authentication proves you hold the private key without transmitting it.
• JWT signing with RS256 / ES256 - the auth server signs tokens with its private key; other services verify them with the public key. The public key can be published openly (often as a JWKS endpoint); only the auth server can issue valid tokens. Covered in the JWT article.
• Code signing- apps, packages, and git commits can be signed with a private key. Anyone with the corresponding public key can verify the signature is genuine and the code hasn't been modified since it was signed.
• End-to-end encrypted messaging - Signal, WhatsApp, and similar apps use asymmetric key exchange so that only the sender and recipient can read messages - not the platform operator.

In almost all of these cases, you are not calling asymmetric encryption functions directly. You are using a protocol (TLS, SSH, JWT) or tool (openssl, ssh-keygen) that handles it. What matters as a developer is understanding which key is which, why the private key must never be shared or logged, and what "the server's private key was compromised" actually means - it means every certificate signed with it must be revoked and reissued, and depending on the protocol, past sessions may be at risk.