Public and Private Keys: How Asymmetric Cryptography Actually Works

The Problem That Asymmetric Cryptography Solves

Imagine you want to send a secret message to someone you have never met, over a network where anyone can intercept traffic. If you use a single shared key to encrypt and decrypt — what is called symmetric encryption — you have an obvious problem: how do you share that key securely in the first place? You cannot send it over the same insecure channel because an eavesdropper would capture it.

This is the key distribution problem, and it stumped cryptographers for decades. Asymmetric cryptography — also called public key cryptography — solves it by using two mathematically linked keys that behave in a particular way: what one key locks, only the other can unlock.

The Two Keys and What They Do

Every asymmetric key pair consists of:

Public key: A value you share freely. Publish it on your website, post it in a key directory, include it in your email signature. Anyone can have it.

Private key: A value you never share with anyone. It stays in your control, ideally protected by hardware security or strong encryption.

The mathematical relationship between the two is one-way: you can derive a public key from a private key, but not the reverse. Given the public key alone, an attacker cannot feasibly calculate the private key — assuming the key size is appropriate and the algorithm is sound.

This asymmetry is what makes two things possible:

Encryption: Anyone can encrypt a message using your public key. Only you, holding the private key, can decrypt it.
Signatures: You can sign data with your private key. Anyone with your public key can verify the signature, confirming it came from you.

Encryption: How a Secure Message Travels

The flow for public key encryption works like this:

Public Key Encryption Flow

  ALICE (sender)                        BOB (recipient)
  ──────────────                        ───────────────
  Has: Bob's public key                 Has: Bob's private key

  Plaintext message
        |
        v
  [ Encrypt with Bob's public key ]
        |
        v
  Ciphertext (unreadable)
        |
        |──────── travels over network ──────>|
                                              |
                                    [ Decrypt with Bob's private key ]
                                              |
                                              v
                                    Original plaintext restored

Key point: even if an attacker intercepts the ciphertext, they cannot decrypt it without Bob’s private key. The public key that encrypted it cannot decrypt it.

In practice, pure asymmetric encryption of large data is slow. Real systems use a hybrid approach: the public key is used to encrypt a randomly generated symmetric key, and that symmetric key encrypts the actual data. TLS does exactly this during its handshake.

Digital Signatures: Proving You Sent It

Signatures work in the opposite direction from encryption. Instead of the sender using the recipient’s public key, the sender uses their own private key.

Digital Signature Flow

  ALICE (signer)                        BOB (verifier)
  ──────────────                        ──────────────
  Has: Alice's private key              Has: Alice's public key

  Original document
        |
        v
  [ Hash the document ]
        |
        v
  Document hash (fixed-length digest)
        |
        v
  [ Encrypt hash with Alice's private key ]
        |
        v
  Signature
        |
        |──── Document + Signature ────>|
                                        |
                              [ Hash the received document ]
                                        |
                              [ Decrypt signature with Alice's public key ]
                                        |
                              [ Compare: do the hashes match? ]
                                        |
                              YES: Document is authentic, unmodified
                              NO:  Document has been tampered with

This achieves two things simultaneously:

Authentication: The signature could only have been created by whoever holds Alice’s private key
Integrity: Any modification to the document after signing will produce a different hash, breaking the signature

The Algorithms Behind the Keys

Different mathematical problems power different asymmetric algorithms. Knowing which algorithm you are using matters because they have different security properties and performance characteristics.

RSA (Rivest-Shamir-Adleman) The oldest and most widely deployed algorithm. Security is based on the difficulty of factoring the product of two large prime numbers. A 2048-bit RSA key is currently considered secure; 4096-bit provides a larger margin. RSA is slower than alternatives and produces large key sizes.

Elliptic Curve Cryptography (ECC) Security is based on the elliptic curve discrete logarithm problem. A 256-bit ECC key provides roughly equivalent security to a 3072-bit RSA key. This makes ECC significantly faster and more efficient — particularly valuable in mobile and embedded contexts. ECDSA (for signatures) and ECDH (for key exchange) are the common ECC-based algorithms.

Ed25519 A specific elliptic curve algorithm using the Edwards curve. Has become popular for SSH keys and modern cryptographic systems because it is fast, produces compact signatures, and has better resistance to certain implementation errors than ECDSA. This is the recommended algorithm for new SSH key generation.

Generating a key pair with OpenSSL:

# RSA 4096-bit
openssl genrsa -out private.pem 4096
openssl rsa -in private.pem -pubout -out public.pem

# Ed25519 (preferred for SSH)
ssh-keygen -t ed25519 -C "your_email@example.com"

Public Key Infrastructure (PKI)

A public key alone does not tell you who owns it. If someone sends you a public key claiming to be your bank, how do you know it is not an attacker’s key? This is the identity problem, and PKI is the solution.

PKI is a system of:

Certificate Authorities (CAs): Trusted third parties that verify identities and issue digital certificates. Browsers and operating systems ship with a list of trusted root CAs.

Digital Certificates (X.509): Documents that bind a public key to an identity (domain name, organization, person). The certificate is signed by the CA’s private key, so anyone with the CA’s public key can verify it.

Certificate Chains: Root CAs typically delegate to intermediate CAs, which issue end-entity certificates. Verification involves checking the entire chain back to a trusted root.

Certificate Chain

  [ Root CA Certificate ]
  (self-signed, trusted by browsers)
         |
         | signs
         v
  [ Intermediate CA Certificate ]
  (signed by Root CA)
         |
         | signs
         v
  [ End-Entity Certificate ]
  (your website's certificate)
  Contains: domain name, public key, validity period, CA signature

When your browser connects to a website over HTTPS, it:

Receives the site’s certificate
Verifies the CA signature using the CA’s public key
Checks that the domain matches
Checks the certificate has not expired and has not been revoked
Uses the public key in the certificate to begin the TLS handshake

Key Exchange: Diffie-Hellman

There is one more scenario to understand: establishing a shared secret between two parties without ever transmitting that secret. This is what Diffie-Hellman key exchange does.

Neither party’s private key is revealed. They exchange public values and each independently derives the same shared secret. This shared secret is then used as the symmetric key for encrypting the session.

Modern TLS uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), where new key pairs are generated for each session (ephemeral). This provides forward secrecy: even if the server’s long-term private key is later compromised, past sessions cannot be decrypted because the session keys were temporary and have been discarded.

Storing and Protecting Private Keys

A private key’s security is only as good as how it is stored. Compromise the private key and the entire system is undermined. Common approaches, from least to most secure:

File-based storage: The key is stored as a file on disk, optionally encrypted with a passphrase. Acceptable for personal use; risky in production servers where the key must be loaded without human interaction.

Environment variables and secrets managers: Keys are injected at runtime from services like AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault. Better than files because access is logged and keys can be rotated without redeployment.

Hardware Security Modules (HSMs): Dedicated hardware that stores the private key and performs cryptographic operations internally. The key never leaves the device. Required for high-assurance environments like certificate authorities, payment systems, and government systems. Cloud-based HSM equivalents (AWS CloudHSM, Azure Dedicated HSM) are now widely used.

FIDO2 / Passkeys: The private key lives on the user’s device in a secure enclave and never leaves it. The site sends a challenge; the device signs it. This is the basis of modern passwordless authentication.

Real-World Applications

HTTPS / TLS: Every HTTPS connection uses certificates (public keys bound to domain identities) to authenticate servers, and key exchange to establish session encryption. Most websites you visit today use ECC-based certificates.

SSH access: Server authentication uses the server’s host key (public key stored in known_hosts). User authentication can use a key pair instead of a password — the server stores the user’s public key, and the client proves possession of the matching private key.

Code signing: Software publishers sign release artifacts with their private key. Package managers, operating systems, and app stores verify signatures before installing software to prevent tampered packages from being installed.

Email (S/MIME and PGP/GPG): Recipients’ public keys encrypt message content; senders’ private keys create signatures. Less common in consumer email but standard in government and high-security enterprise environments.

Cryptocurrency: Wallet addresses are derived from public keys. Spending funds requires signing a transaction with the private key. Lose the private key, lose access to the funds — permanently.

Passkeys (2024-2026 mainstream adoption): The fastest-growing application of asymmetric cryptography right now. Passkeys use device-bound key pairs (often protected by biometrics) to replace passwords. Google, Apple, Microsoft, and most major services now support them.

The Quantum Computing Threat

Current asymmetric algorithms — RSA, ECDSA, ECDH — are secure against classical computers. A quantum computer running Shor’s algorithm could break them. This is not an immediate threat; sufficiently powerful quantum computers do not exist yet. But the concern is real enough that NIST finalized its first post-quantum cryptography standards in 2024.

The new standards include:

ML-KEM (CRYSTALS-Kyber): For key encapsulation / key exchange
ML-DSA (CRYSTALS-Dilithium): For digital signatures
SLH-DSA (SPHINCS+): Signature scheme based on hash functions

Organizations managing long-lived sensitive data — government records, healthcare, financial — are beginning migration planning now. The concern is “harvest now, decrypt later”: an adversary could capture encrypted traffic today and decrypt it once quantum computers are capable enough.

For most organizations, the immediate action is to ensure they are using TLS 1.3 (which supports forward secrecy) and to track NIST post-quantum standards as they are adopted in TLS and other protocols over the next several years.

Quick Reference

Key Operations Summary

  Operation             | Key Used           | Purpose
  ──────────────────────|────────────────────|─────────────────────────
  Encrypt message       | Recipient's PUBLIC | Confidentiality
  Decrypt message       | Recipient's PRIVATE| Confidentiality
  Create signature      | Sender's PRIVATE   | Authentication + Integrity
  Verify signature      | Sender's PUBLIC    | Authentication + Integrity
  TLS certificate check | CA's PUBLIC        | Identity verification
  ECDHE key exchange    | Ephemeral pairs    | Session key derivation

Understanding how these operations map to key usage removes most of the confusion people encounter when first working with asymmetric cryptography. The pattern is consistent across every application: public keys are for locking and verifying, private keys are for unlocking and signing.