An Asymmetric Encryption Example, Explained for Developers

A simple asymmetric encryption example is this: I generate a key pair, publish the public key, and anyone can use it to encrypt a message that only my matching private key can decrypt. The two keys are mathematically linked but not interchangeable — encrypt with one, decrypt with the other — and that asymmetry is what lets strangers communicate securely without ever sharing a secret in advance.

Let me walk through a working example of asymmetric encryption and then show where you already rely on it every day.

Symmetric vs asymmetric in one paragraph

Symmetric encryption uses a single shared key for both encryption and decryption — fast, but everyone who needs to read the data must first obtain the same secret, which is the hard part. Asymmetric encryption uses a pair: a public key you can hand out freely and a private key you guard. Anyone can encrypt to you; only you can decrypt. It solves the key-distribution problem that symmetric crypto cannot.

An asymmetric encryption example with RSA

RSA is the most recognizable public-key algorithm, so it makes a good first example of asymmetric encryption. Generate a 3072-bit key pair with OpenSSL:

# Private key — keep this secret
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out private.pem

# Public key — safe to distribute
openssl pkey -in private.pem -pubout -out public.pem

Now encrypt a short message with the public key and decrypt it with the private key:

echo "meet at the usual place" > message.txt

# Anyone with public.pem can do this
openssl pkeyutl -encrypt -pubin -inkey public.pem \
  -in message.txt -out message.enc

# Only the holder of private.pem can reverse it
openssl pkeyutl -decrypt -inkey private.pem \
  -in message.enc -out decrypted.txt

decrypted.txt matches the original. The public key that produced the ciphertext cannot undo it — that is the entire security property. Use 3072-bit RSA or larger; 1024-bit keys are considered broken and 2048 is the practical minimum for anything new.

The same trick in code

Here is the equivalent example of asymmetric encryption in Python using the cryptography library, which most teams should prefer over hand-rolled crypto:

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import hashes

private_key = rsa.generate_private_key(public_exponent=65537, key_size=3072)
public_key = private_key.public_key()

message = b"meet at the usual place"

ciphertext = public_key.encrypt(
    message,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None,
    ),
)

plaintext = private_key.decrypt(ciphertext, padding.OAEP(
    mgf=padding.MGF1(algorithm=hashes.SHA256()),
    algorithm=hashes.SHA256(),
    label=None,
))

Note the OAEP padding. Textbook RSA without proper padding is insecure, and this is a place where "just use RSA" quietly goes wrong. Always use a vetted library and a modern padding scheme.

Encryption is only half of it — signatures use the pair backwards

The key pair also powers digital signatures, and this is where a lot of the real value lives. Sign with your private key, and anyone with your public key can verify the signature. That proves the message came from you and was not altered. It is the same asymmetry, run in the opposite direction: private key operates, public key checks.

This is exactly how signed software releases and signed commits work. The publisher signs an artifact with a private key; you verify it with their published public key before trusting the code.

Where you already use it

You lean on asymmetric encryption constantly, usually without noticing:

• TLS/HTTPS: the handshake uses public-key crypto to authenticate the server and negotiate a fast symmetric session key. This hybrid approach is the norm — asymmetric to bootstrap, symmetric for bulk data.
• SSH: your SSH key pair authenticates you to servers without sending a password.
• Package and commit signing: verifying that a dependency or release is genuine.
• Certificate chains: the entire web PKI is signatures verifying signatures up to a trusted root.

That last point matters for supply chain security. Signatures only prove where an artifact came from, not that its contents are free of known vulnerabilities. A correctly signed package can still ship a critical CVE, which is why verification and scanning are complementary. An SCA tool checks the contents; signing checks the origin.

Practical guidance

• Never invent your own scheme. Use OpenSSL, libsodium, or a language-standard crypto library.
• Protect private keys like the crown jewels — a leaked private key nullifies the entire scheme.
• For encrypting large data, use the hybrid pattern: asymmetric to exchange a symmetric key, symmetric for the payload.
• Prefer modern algorithms; for new signing work, Ed25519 is a strong, fast default alongside RSA.

FAQ

What is a simple asymmetric encryption example?

Generate an RSA key pair, share the public key, and let anyone encrypt a message with it. Only your private key can decrypt that message. The public key cannot reverse its own encryption, which is the security guarantee.

What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses one shared key for both directions and is fast but requires securely distributing that key. Asymmetric encryption uses a public/private key pair, solving key distribution because the public key can be shared openly.

Is RSA still secure?

Yes, at adequate key sizes (3072-bit or larger) and with proper padding like OAEP. Avoid 1024-bit keys and never use textbook RSA without padding. Many teams also adopt elliptic-curve alternatives for smaller keys and faster operations.

Why is asymmetric encryption slower than symmetric?

The underlying math (large modular exponentiation for RSA) is far more expensive than symmetric ciphers. That is why real systems use it only to authenticate and exchange a symmetric key, then switch to symmetric encryption for the actual data.