Asymmetric Encryption Example: RSA Explained Step by Step

Short answer: the classic asymmetric encryption example is RSA. You encrypt a message with someone’s public key, and only their matching private key can decrypt it. Every HTTPS connection relies on public-key cryptography, and the worked example below walks through RSA with numbers small enough to check on a calculator.

Updated September 2026. We’ve added a step-by-step RSA example with small numbers, corrected how TLS 1.3 and digital signatures work, updated key-size advice, and added a section on post-quantum cryptography.

Asymmetric encryption, also called public-key cryptography, uses two mathematically linked keys. The public key can be shared with anyone. The private key is kept secret by its owner.

Data encrypted with someone’s public key can only be decrypted with their matching private key. And a digital signature made with a private key can be checked by anyone who has the public key.

This guide walks through a real asymmetric encryption example you can check with a calculator, then covers where you’ll find public-key cryptography in everyday life.

Symmetric vs asymmetric encryption

Symmetric encryption uses one shared secret key for both encryption and decryption. Algorithms such as AES are fast, so they handle bulk data like files, disks and web traffic. The hard part is getting the same key to both sides safely.

Asymmetric encryption solves that problem. You can publish your public key openly, and only your private key can undo what it protects. The trade-off is speed: public-key operations are much slower, so they’re mainly used to agree on keys and to sign data.

Most real systems use both. Public-key cryptography sets up a shared secret, then symmetric encryption protects the actual data. Our guide to common encryption methods compares the main algorithms in each family.

A simple asymmetric encryption example in plain English

Imagine Mary wants people to send her private files.

1. Mary generates a key pair. She keeps the private key on her own device and publishes the public key.
2. John wants to send Mary a file. He encrypts it with Mary’s public key.
3. Anyone who intercepts the file sees only scrambled data. Even John can’t decrypt it now.
4. Mary decrypts the file with her private key.

Think of the public key as an open padlock that Mary hands out to anyone. Anyone can snap it shut on a box, but only Mary has the key that opens it.

Signatures work the other way around. If Mary wants to prove a message came from her, she signs it with her private key. Anyone can check the signature with her public key. If the message is changed, the check fails.

Worked RSA example with small numbers

RSA is the classic asymmetric algorithm, named after Ron Rivest, Adi Shamir and Leonard Adleman. The numbers below are tiny so you can follow each step. Real RSA keys use numbers that are hundreds of digits long.

Step 1: Create the key pair

1. Pick two prime numbers: p = 61 and q = 53.
2. Multiply them to get the modulus: n = 61 × 53 = 3233. This is part of both keys.
3. Compute φ(n) = (p − 1) × (q − 1) = 60 × 52 = 3120.
4. Choose a public exponent e = 17. It must share no factors with 3120, and it doesn’t.
5. Find the private exponent d so that (e × d) mod 3120 = 1. Here d = 2753, because 17 × 2753 = 46,801 = 15 × 3120 + 1.

The public key is (n = 3233, e = 17). The private key is (n = 3233, d = 2753). The primes 61 and 53 are thrown away or kept secret, because anyone who knows them can work out d.

Step 2: Encrypt with the public key

Say the message is the number m = 65. (In practice, text is converted to numbers and padded first.) John computes:

c = me mod n = 6517 mod 3233 = 2790

He sends the ciphertext 2790 to Mary.

Step 3: Decrypt with the private key

Mary computes:

m = cd mod n = 27902753 mod 3233 = 65

She gets back the original message, 65. Without d, an attacker would need to factor 3233 into 61 × 53. That’s trivial for small numbers but not practical for a properly sized 2048-bit or larger modulus with today’s computers.

Step 4: Sign with the private key, verify with the public key

To sign the same value, Mary uses her private exponent:

s = md mod n = 652753 mod 3233 = 588

Anyone can check it with the public key:

se mod n = 58817 mod 3233 = 65

The result matches the message, so the signature is valid. Real systems sign a hash of the message rather than the message itself.

You can check all of these numbers in Python with pow(65, 17, 3233), pow(2790, 2753, 3233) and pow(588, 17, 3233).

Why textbook RSA isn’t used as-is

This “textbook” version is for learning only. Real RSA uses random padding such as OAEP for encryption and PSS for signatures, as defined in RFC 8017. Without padding, RSA leaks patterns and can be attacked. Use a well-tested library instead of writing RSA yourself. Our list of cryptography tools covers trusted options.

RSA key sizes in 2026

NIST treats 2048-bit RSA as the minimum acceptable size. It provides about 112 bits of security. For data that must stay protected well beyond 2030, NIST’s key-management guidance points to 3072-bit RSA or larger, which gives about 128 bits of security.

Keys of 1024 bits or less are no longer considered secure and shouldn’t be used. Elliptic-curve keys give similar strength with much smaller keys. For example, a 256-bit elliptic curve key is roughly equal to 3072-bit RSA.

Common asymmetric encryption examples in real life

1. HTTPS and TLS 1.3

Every time you visit an HTTPS site, public-key cryptography is at work. In TLS 1.3, the browser and server agree on a shared key using ephemeral elliptic-curve Diffie-Hellman (ECDHE) or finite-field Diffie-Hellman. TLS 1.3 removed the old method of encrypting the session key with the server’s RSA key.

The server proves its identity by signing the handshake with the private key that matches its certificate. That signature can use RSA (RSA-PSS), ECDSA or EdDSA. After the handshake, all web traffic is encrypted with a fast symmetric cipher such as AES-GCM or ChaCha20-Poly1305.

2. Digital signatures and code signing

Software updates, documents and emails are signed with the publisher’s private key. Your device checks the signature with the public key before trusting the file. NIST’s Digital Signature Standard, FIPS 186-5, approves RSA, ECDSA and EdDSA for signatures. The older DSA algorithm is no longer approved for creating new signatures.

3. Encrypted email

OpenPGP and S/MIME use public keys to encrypt a message’s one-time symmetric key and to sign messages. Only the recipient’s private key can open the message.

4. SSH and secure logins

System administrators log into servers with SSH key pairs instead of passwords. The server stores the public key, and the user proves they hold the private key. Passkeys use the same idea to replace website passwords.

5. Cryptocurrency

Bitcoin and many other cryptocurrencies use elliptic-curve signatures. Your private key signs transactions, and the network checks them with your public key. The private key is never shared. If it’s lost or stolen, so are the funds.

6. Key exchange with Diffie-Hellman

Diffie-Hellman lets two parties create a shared secret over an open network without ever sending the secret. The elliptic-curve version, ECDH, is used in TLS, Signal, WhatsApp and many VPNs. Our article on elliptic curve cryptography explains how it works.

RSA vs ECC: a side-by-side example

RSA and elliptic-curve cryptography (ECC) do the same jobs, key exchange and digital signatures, but ECC reaches the same strength with much smaller keys. NIST’s key-management guide, SP 800-57 Part 1 Rev. 5 (Table 2), lines them up like this:

You can see the difference yourself with OpenSSL. Both commands below make a key at roughly 128-bit strength:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa.pem
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ec.pem

The RSA public key carries a 384-byte modulus and each RSA-3072 signature is 384 bytes. A P-256 public key is 65 bytes uncompressed, and an ECDSA signature holds two 32-byte values (about 64 bytes before encoding). Ed25519 is smaller still: a 32-byte public key and a 64-byte signature (RFC 8032).

In practice, that’s why TLS 1.3 key exchange uses ECDHE (usually X25519) and many newer systems sign with Ed25519 or ECDSA, while RSA sticks around in older certificates and systems that need it for compatibility. Signing is also faster with ECC; RSA is faster at verifying signatures. Neither is safe against a large quantum computer, which is what the next section covers.

Post-quantum cryptography: what’s changing

A large enough quantum computer could break RSA, Diffie-Hellman and elliptic-curve cryptography using Shor’s algorithm. No such machine exists today, but attackers could record encrypted traffic now and decrypt it later. That’s why the move to new algorithms has already started.

In August 2024, NIST published its first three post-quantum standards:

• FIPS 203, ML-KEM: a key-encapsulation mechanism for setting up shared keys. It’s the main replacement for RSA and Diffie-Hellman key exchange.
• FIPS 204, ML-DSA: the main post-quantum digital signature algorithm.
• FIPS 205, SLH-DSA: a hash-based signature algorithm, used as a backup that relies on different math.

NIST’s draft transition plan, NIST IR 8547, proposes deprecating quantum-vulnerable algorithms such as RSA, ECDSA and ECDH at the 112-bit security level after 2030. It proposes disallowing them entirely after 2035. The report is still a draft, but it’s the clearest signal of NIST’s intended timeline.

Many browsers and messaging apps already use “hybrid” key exchange that combines a classic algorithm such as X25519 with ML-KEM. Organizations should start by taking an inventory of where they use RSA and elliptic-curve cryptography.

FIPS 203, 204 and 205 at a glance

The new algorithms have much bigger keys and signatures than ECC. These sizes come straight from the standards (FIPS 203 Table 3, FIPS 204 Table 2, FIPS 205 Table 2):

Compare that with the 32-byte X25519 key and 64-byte Ed25519 signature above. The size jump is the main practical cost of moving to post-quantum crypto. OpenSSL added ML-KEM, ML-DSA and SLH-DSA in version 3.5; see our list of cryptography tools for OpenSSL and other tools you can test them with, and our overview of common encryption methods for where these fit next to AES and ChaCha20.

For a quick daily roundup of encryption news and other security updates, sign up for the CyberExperts Daily Brief.

Frequently asked questions

Sources

• IETF RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: rfc-editor.org
• IETF RFC 8017, PKCS #1: RSA Cryptography Specifications Version 2.2: rfc-editor.org
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: csrc.nist.gov
• NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths: csrc.nist.gov
• NIST FIPS 186-5, Digital Signature Standard: csrc.nist.gov
• NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA): nist.gov announcement (Aug 2024)
• NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards: csrc.nist.gov
• CISA, Post-Quantum Cryptography Initiative: cisa.gov/quantum

George Mutune

I am a cyber security professional with a passion for delivering proactive strategies for day to day operational challenges. I am excited to be working with leading cyber security teams and professionals on projects that involve machine learning & AI solutions to solve the cyberspace menace and cut through inefficiency that plague today's business environments.

Keep Reading

Explore more →

How to Encrypt Your Internet Connection: 7 Methods That Work

Encrypt your internet connection in 2026: force HTTPS, turn on encrypted DNS, secure your Wi-Fi, and when a VPN, iCloud Private Relay or Tor actually helps.

Common Encryption Methods in 2026

Practical 2026 guide: AES-GCM, ChaCha20-Poly1305, RSA/ECC, NIST PQC (ML-KEM, ML-DSA, SLH-DSA), TLS 1.3, and legacy algorithms to retire.

Why Hardware Encryption is Not Secure

Hardware Encryption is not Secure A Little History… In the past, it was assumed that hardware encryption is far more…