Why Can Public Key Encrypt but Not Decrypt? Unpacking HTTPS Encryption

Symmetric and Asymmetric Encryption

Symmetric encryption uses a single secret key for both encryption and decryption. The same key that transforms plaintext into ciphertext is also used to recover the original data.

Asymmetric encryption (public‑key cryptography) uses a key pair: a public key that can be freely distributed to encrypt data, and a private key that is kept secret and used to decrypt the ciphertext.

Why a Public Key Cannot Decrypt

Public‑key algorithms rely on mathematical operations that are easy to compute in one direction but infeasible to reverse without secret information. For example, modular exponentiation: 5^2 mod 7 = 25 mod 7 = 4 produces the ciphertext 4 from the plaintext 5. Recovering the original exponent from the result requires solving a discrete logarithm problem, which is computationally hard for large moduli. Only the holder of the private key can efficiently compute the inverse, so the public key cannot be used for decryption.

HTTPS Encryption Process (TLS 1.2)

HTTPS = HTTP + TLS. TLS 1.2 is the most widely deployed version. The protocol consists of two logical phases:

Phase 1 – Asymmetric handshake : the client and server exchange three random values (client random, server random, pre‑master secret) using public‑key cryptography. From these values both sides derive a shared session key .

Phase 2 – Symmetric data transfer : the session key is used as the symmetric key for encrypting all application data, providing high‑performance confidentiality and integrity.

TLS 1.2 Handshake Steps

ClientHello

: the client advertises supported TLS version (e.g., TLS 1.2), cipher suites, and a 32‑byte client random . ServerHello: the server returns a server random , selects the protocol version and cipher suite, and sends its X.509 digital certificate containing the server’s public key. Certificate: (optional) additional certificate chain from intermediate CAs. ServerKeyExchange: sent only for certain key‑exchange methods (e.g., Diffie‑Hellman). ServerHelloDone: signals the end of the server’s part. ClientKeyExchange: the client generates a random pre_master_secret , encrypts it with the server’s public key extracted from the certificate, and sends the ciphertext to the server. ChangeCipherSpec (client): both parties now compute the master secret from client random, server random, and pre_master_secret, then derive the symmetric session keys (encryption, MAC, IV). Finished (client): a hash of all handshake messages, encrypted with the newly derived session key, is sent to the server for integrity verification. ChangeCipherSpec (server): the server performs the same key derivation and switches to the session keys. Finished (server): the server sends its own encrypted hash, completing the handshake.

After these four round‑trips the TLS handshake is finished and all subsequent HTTP traffic is protected with fast symmetric encryption (e.g., AES‑GCM).

Certificates and the Role of the Certificate Authority (CA)

The server’s certificate contains its public key and is signed by a trusted CA. The CA’s private key creates the signature; the client verifies the signature using the CA’s public key, which is pre‑installed in the operating system or browser. This mechanism prevents an attacker from substituting a forged public key because the client would detect an invalid signature.

Why Both Asymmetric and Symmetric Encryption Are Needed

Asymmetric algorithms (RSA, ECDSA, etc.) are computationally expensive and unsuitable for bulk data. Symmetric algorithms (AES, ChaCha20) are orders of magnitude faster. The handshake uses asymmetric cryptography only to securely exchange the secret (pre_master_secret). Once the secret is shared, symmetric encryption handles the high‑throughput data transfer.

Key Takeaways

Modular exponentiation (or similar one‑way functions) makes public‑key encryption one‑way; reversing it without the private key is infeasible.

HTTPS = HTTP + TLS 1.2; TLS adds a four‑message handshake that creates a unique symmetric session key for each connection.

The handshake involves two key pairs: the server’s own public/private keys and the CA’s public/private keys used to sign the server certificate.

Three random values (client random, server random, pre_master_secret) are combined to derive the master secret and then the session keys, guaranteeing fresh keys for every TLS session.

Asymmetric encryption secures the key exchange; symmetric encryption provides efficient confidentiality and integrity for the data payload.