How Public-Key Encryption Works: A Simple Example

Public-key encryption works with a matched pair of keys. Anyone can use the public key to turn readable plaintext into ciphertext, but only the holder of the corresponding private key can decrypt that ciphertext. The private key never needs to be sent to the person encrypting the message.

This solves a tricky problem: two people can begin communicating securely even if they have not already shared a secret key. The core mechanism is simple enough to follow with one padlock-like public key, one hidden private key, and a six-word message.

Why public-key encryption matters

Traditional symmetric encryption uses the same secret key to encrypt and decrypt. It can be fast and strong, but the sender and recipient first need a secure way to share that secret. Sending the key through the same exposed channel as the message would hand an eavesdropper both ingredients.

Public-key cryptography separates the jobs. The recipient distributes a public key widely and protects a private key. A sender can therefore secure information for that recipient without learning the decryption key. This idea supports encrypted messaging, secure connections, and key-establishment systems, although real protocols add authentication and other protections.

Public and private keys: one pair, different jobs

A key-generation algorithm creates two mathematically related values. The public key is meant to be shared. The private key must remain under its owner’s control. With a properly chosen modern algorithm, parameters, and key size, knowing the public key does not provide a practical route to calculating the private key.

The padlock metaphor helps: Amina can hand out open padlocks that anyone may snap shut around a box, while keeping the only unlocking key. The metaphor is not the mathematics. Actual schemes perform defined operations on numbers and require secure randomness, approved parameter choices, and correct padding or encoding.

Example: Amina and Ben send a six-word message

Amina generates a public–private key pair. She publishes the public key and stores the private key securely. Ben wants to send: “Meet by the library at six.” It contains six words, but the process would be the same for any permitted plaintext input.

Ben obtains Amina’s authentic public key. He does not need her private key.
His encryption software combines the plaintext, Amina’s public key, and scheme-required randomness to produce ciphertext: data that does not reveal the sentence to an observer.
Ben sends the ciphertext. It is safe for the ciphertext to cross a network that an eavesdropper can observe or copy, assuming the scheme and keys are secure and implemented correctly.
Amina’s software applies her private key through the matching decryption algorithm and recovers the six-word plaintext.

Good randomized encryption also means encrypting the same sentence twice should not simply produce the same ciphertext twice. That matters because predictable ciphertext could reveal patterns even when an attacker cannot read the underlying words.

Ben encrypts a six-word message with Amina’s public key; Amina uses the matching private key to recover it.

What an eavesdropper can see

An eavesdropper can see Amina’s public key and copy Ben’s ciphertext. Neither item is supposed to be secret. Security depends on the encryption problem being computationally infeasible to reverse without the private key, not on hiding the algorithm or pretending that ciphertext cannot be copied.

That protection has boundaries. Stolen private keys, weak random-number generation, obsolete algorithms, unsafe parameters, software bugs, or side-channel leaks can defeat a system without solving its underlying mathematical problem. Cryptography is a component of security, not a force field around a careless implementation.

An eavesdropper may copy the public key and ciphertext, but secure algorithms make recovering the message impractical without the private key.

How real systems use the idea

Public-key operations are relatively expensive and can handle only suitably encoded inputs. Real systems commonly use asymmetric cryptography to authenticate parties and establish a temporary shared secret, then use fast symmetric authenticated encryption for the actual data. This combination is called hybrid encryption.

There is also an identity problem. If an attacker replaces Amina’s published public key with the attacker’s key, Ben may encrypt securely for the wrong person. Certificates, trusted directories, fingerprints, and other verification methods bind a public key to the intended owner. Public does not automatically mean authentic.

Encryption is not the same as a digital signature

Encryption and signatures can use public–private key pairs, but they answer different questions. For confidentiality, Ben encrypts for the recipient using Amina’s public key, and Amina decrypts with her private key. The goal is to keep the content secret from everyone else.

For a digital signature, Amina’s software signs data using her private key, and other people verify the signature using her public key. The goal is authenticity and integrity: evidence that the private-key holder signed particular data and that it was not altered. Saying a signature is merely “encryption with the private key” is misleading because secure signature schemes have distinct operations and security requirements.

Encryption uses the recipient’s public key for confidentiality; a signature uses the sender’s private key so others can verify authenticity with the public key.

Common misconceptions and boundaries

The public key is not a shared password. It is designed for distribution, while the private key is the secret.
Public-key encryption does not prove who sent a message. Confidentiality and sender authentication are separate properties.
The private key should not be emailed to a sender. If Ben needs it to encrypt, the system has lost the main advantage of the key pair.
The simple lock story omits algorithm choices, padding, randomness, certificates, key rotation, and revocation. Those details are not optional in production systems.