Asymmetric Encryption: Key Pairs, Signatures and Hybrid Cryptography

Asymmetric encryption uses two mathematically related keys instead of one shared secret. What one key locks, only the other can unlock — and knowing the public key does not let you derive the private one. That property solves the problem symmetric cryptography cannot: establishing security with someone you have never met and share no secret with.

The key distribution problem it solves

Symmetric encryption is fast and requires both parties to already hold the same key. Getting that key to the other party securely is the difficulty, and it does not scale — n parties who all need to talk privately require a key pair count that grows quadratically.

With asymmetric cryptography each party has one key pair. The public key is published freely; the private key never leaves its owner. Anyone can encrypt to you using your published key, and only you can read the result. The number of keys grows linearly, and no secret has to be exchanged beforehand.

Two operations, opposite directions

This is the part most worth getting straight, because exam questions turn on it.

For confidentiality, encrypt with the recipient's public key. Only the recipient's private key decrypts it. Anyone can send you a confidential message; only you can read it.

For authenticity, sign with the sender's private key. Anyone with the sender's public key can verify it, which proves the message came from the holder of that private key and has not been altered. That is the basis of digital signatures and of the non-repudiation property — the signer cannot plausibly deny signing, because only they hold the key.

In practice signing does not encrypt the whole message. The message is hashed, and the hash is signed, which is far faster and produces a fixed-size signature. Change one byte of the message and the hash no longer matches. This is exactly the mechanism behind code signing.

Confidentiality and authenticity can be combined by signing then encrypting, and the order matters for some protocols.

Why everything is actually hybrid

Asymmetric operations are orders of magnitude slower than symmetric ones and are impractical for bulk data. So real systems use both.

A TLS session establishes a shared symmetric key using asymmetric cryptography, then encrypts all the actual traffic symmetrically with that key. Encrypted email does the same: the message is encrypted with a randomly generated symmetric key, and that key is encrypted to each recipient's public key.

The rule to remember: asymmetric for key exchange and authentication, symmetric for the data. When a question asks which is used for bulk encryption, the answer is symmetric, every time.

Modern key exchange uses ephemeral Diffie-Hellman, generating a fresh key per session so that compromising a long-term private key later does not decrypt previously captured traffic — the property called forward secrecy, and the reason interception appliances cannot simply replay a stored key, as discussed under TLS proxies.

RSA, ECC, and what comes next

RSA rests on the difficulty of factoring large numbers. It is well understood and widely supported, and it needs large keys — 2048 bits as a current minimum, 3072 or more for longer-term protection.

Elliptic curve cryptography rests on a different hard problem and achieves comparable strength with far smaller keys: a 256-bit elliptic curve key is roughly equivalent to a 3072-bit RSA key. Smaller keys mean faster operations and less data on the wire, which is why ECC dominates new deployments and mobile and embedded use.

Diffie-Hellman is key exchange rather than encryption — it lets two parties derive a shared secret over a public channel without transmitting it. Its elliptic curve variant is what most TLS sessions use today.

Post-quantum algorithms are being standardized because a sufficiently capable quantum computer would break RSA and ECC. The practical concern now is harvest-now-decrypt-later: traffic captured today and stored until it can be decrypted. Migration has begun in protocols that protect long-lived secrets.

The part that actually fails

The mathematics rarely breaks. Key management does.

A public key is only useful if you know whose it is, which is what certificates and certificate authorities establish — and why a proxy presenting a certificate your client blindly trusts defeats the whole scheme. Private keys must be generated and stored somewhere they cannot be copied, ideally hardware-backed. Where recovery of encrypted data is a business requirement, the trade-offs are those described under key escrow — and signing keys are never escrowed, because that destroys non-repudiation.

Exam angles

Know that encryption uses the recipient's public key and signing uses the sender's private key. Know that asymmetric provides confidentiality, authentication, integrity and non-repudiation, while symmetric provides confidentiality and speed, and that real systems combine them. Compare RSA and ECC on key size for equivalent strength, identify Diffie-Hellman as key exchange rather than encryption, and recognize forward secrecy and the post-quantum migration as current considerations.