Public Key Encryption: Mermaid Flowchart Diagram

About Source

Public key encryption (asymmetric encryption) is a cryptographic system that uses a mathematically linked key pair — a public key that anyone can use to encrypt data, and a private key that only the owner can use to decrypt it.

Unlike symmetric encryption where both parties share the same secret key, asymmetric encryption solves the key distribution problem: you can publish your public key openly without any security risk, because data encrypted with it can only be decrypted by the corresponding private key, which never leaves your possession.

The mathematical foundation relies on trapdoor functions — operations that are easy to compute in one direction but computationally infeasible to reverse without specific information. RSA uses the difficulty of factoring large integers; elliptic-curve cryptography (ECC) uses the discrete logarithm problem on elliptic curves. In practice, RSA-2048 and RSA-4096 are common for legacy systems, while ECDSA and ECDH with P-256 or Curve25519 are preferred in modern protocols like TLS 1.3 for their smaller key sizes and faster operations.

The encryption workflow begins with the sender obtaining the recipient's authentic public key — typically from a TLS certificate or a key server. The sender generates a random symmetric session key, encrypts the actual message payload with this session key using AES (a symmetric cipher), then encrypts the session key itself with the recipient's public key. This hybrid approach is used because asymmetric encryption is orders of magnitude slower than symmetric encryption and cannot efficiently handle large payloads.

The recipient uses their private key to decrypt the session key, then uses the session key to decrypt the message. This is exactly how TLS key exchange works: the client and server use asymmetric cryptography to establish a shared symmetric session key, then all subsequent data is encrypted symmetrically.

Public key encryption also underpins digital signatures — see Digital Signature Workflow for how private keys sign data that anyone with the public key can verify. The role of public keys in TLS is covered in TLS Certificate Validation.

Frequently asked questions

Public key encryption (asymmetric encryption) uses a mathematically linked key pair. Data encrypted with the public key can only be decrypted by the corresponding private key. The public key can be distributed openly; only the private key must remain secret. This solves the key distribution problem that symmetric encryption cannot address.

Symmetric encryption uses a single shared secret key for both encryption and decryption — it is fast and suitable for bulk data. Asymmetric encryption uses a key pair and is orders of magnitude slower, so in practice it is used only to securely exchange a symmetric session key, which then encrypts the actual data. TLS uses this hybrid approach.

The sender generates a random symmetric session key, encrypts the data with that key using AES, then encrypts the session key itself with the recipient's public key. The encrypted session key and encrypted data are sent together. The recipient decrypts the session key with their private key, then uses the session key to decrypt the data.

RSA relies on the difficulty of factoring large integers and requires key sizes of 2048–4096 bits for adequate security. ECC (ECDSA, ECDH) relies on the elliptic-curve discrete logarithm problem and achieves equivalent security with 256-bit keys, resulting in faster operations and smaller certificates. Modern TLS 1.3 strongly favors ECC.

Asymmetric encryption is 100–1000× slower than symmetric encryption and has strict size limits tied to the key size (RSA can only encrypt data smaller than the key). Encrypting bulk data asymmetrically is impractical. The standard pattern is hybrid encryption: use asymmetric cryptography only to exchange a symmetric key, then use the symmetric key for the actual data.

mermaid

flowchart TD
    A[Sender has plaintext message] --> B[Obtain recipient's public key]
    B --> C[Generate random symmetric session key]
    C --> D[Encrypt message payload\nwith session key via AES]
    C --> E[Encrypt session key\nwith recipient's public key via RSA/ECC]
    D --> F[Bundle: encrypted payload\n+ encrypted session key]
    E --> F
    F --> G[Transmit to recipient]
    G --> H[Recipient receives bundle]
    H --> I[Decrypt session key\nwith private key]
    I --> J{Private key valid?}
    J -- Yes --> K[Recover symmetric session key]
    J -- No --> L[Decryption fails]
    K --> M[Decrypt payload\nwith session key]
    M --> N[Plaintext message recovered]