How Asymmetric Encryption Actually Works - The Complete Story

Introduction

Asymmetric encryption seems paradoxical at first: You share your encryption key publicly, send encrypted messages over unencrypted channels, and somehow only the intended recipient can read them. How is this possible?

As a security consultant, I encounter this question constantly in my work. When I review an organization's security architecture, clients often ask: "Why is it safe to publish our SSL certificate?" or "How can our public key be public if it's supposed to be secure?" or "Why do we trust that the API endpoint is really who it claims to be?" These are all applications of asymmetric encryption, and they all seem to contradict basic security principles until you understand the mathematics underneath.

I've also seen the confusion it causes:

  • Developers implementing encryption incorrectly because they don't understand why the math works
  • Security teams unable to explain to their leadership why public key infrastructure is trustworthy
  • Organizations making poor decisions about key management because the fundamental concepts aren't clear
  • Penetration testers missing vulnerabilities because they don't understand where the real security lies

This blog post exists so I can point clients and colleagues to a detailed explanation. It walks you through the complete story of how asymmetric encryption works, from mathematical foundations to real-world applications, explaining why it's secure even when everything is public. Whether you're implementing security, auditing it, or just trying to understand why your HTTPS certificate is safe to make public, this post explains the complete picture.

The Core Problem: Secure Communication Over Insecure Channels

Imagine two people, Alice and Bob, want to communicate securely over the internet. The internet is inherently insecure - anyone can intercept messages.

With symmetric encryption (one shared key), they face an impossible problem:

  • They need to share a secret key first
  • But how do they share it securely over an insecure channel?
  • They're stuck in a chicken-and-egg situation

Asymmetric encryption solves this by using one-way mathematical functions.

The Mathematics: One-Way Functions

The magic of asymmetric encryption relies on mathematical operations that have a special property: they're easy to compute in one direction, but virtually impossible to reverse without special information. This is the concept of a "one-way function" or "trap-door function."

Example: Multiplying vs. Factoring

The magic of asymmetric encryption relies on a mathematical asymmetry:

Easy direction (multiplication):

7 × 13 = 91

This takes seconds. Anyone can do it.

Hard direction (factoring):

91 = ? × ?

For a small number like 91, this is easy—you can figure out it's 7 × 13. But the key insight is what happens with much larger numbers.

With numbers hundreds of digits long:

Easy direction (still fast):

large_prime_1 × large_prime_2 = huge_number

Multiplication is still just multiplication. A computer can multiply two 308-digit numbers in milliseconds.

Hard direction (becomes impossible):

huge_number = ? × ?

But if I give you a 617-digit number (the result of multiplying two 309-digit primes) and ask you to find the original two primes, that's a different story. There's no known efficient algorithm to factor such a large number. The best algorithms we have would take thousands of years on today's fastest computers.

This is the foundation of RSA encryption. The security comes from this mathematical asymmetry: multiplication is easy in both directions, but factoring becomes computationally infeasible as numbers get large.

How Asymmetric Encryption Actually Works: Step by Step

Step 1: Key Generation (The Secret Trap Door)

When Bob wants to receive encrypted messages, he generates a key pair. Here's what happens:

1. Choose two large prime numbers: p = 61, q = 53

2. Multiply them: n = p × q = 3233
   (In real RSA: multiply two 309-digit primes to get 617 digits)

3. Calculate φ(n) = (p-1)(q-1) = 60 × 52 = 3120
   (This is Euler's totient function)

4. Choose encryption exponent: e = 17
   (Must satisfy certain mathematical properties)

5. Calculate decryption exponent: d = 2753
   (Such that: e × d ≡ 1 (mod φ(n)))
   (Only computable if you know p and q)

Result:

  • Public Key: (n=3233, e=17) ← SHARED WITH WORLD
  • Private Key: (n=3233, d=2753) ← LOCKED IN VAULT

Why is this secure?

Everyone knows:

  • n = 3233
  • e = 17

But to find d, an attacker needs:

  • Know φ(n), which requires factoring n into p and q
  • With 2048-bit numbers, factoring would take millennia

With small numbers like 3233, factoring is trivial (61 × 53 = 3233). But with 2048-bit numbers (617 digits), there's no practical way to factor them. The best factoring algorithms we have would take thousands of years.

Step 2: Encryption Over Public Channel

Alice wants to send the message: M = "HELLO" (represented as the number 1819)

She obtains Bob's public key from a public directory or website:

Bob's Public Key: (n=3233, e=17)

She encrypts:

C = M^e mod n
C = 1819^17 mod 3233
C = 1234  (the encrypted message)

Alice sends "1234" over the internet - completely unencrypted!

Anyone can see it:

Message sent: 1234
Alice's IP: 192.168.1.1
Bob's IP: 192.168.1.2
Protocol: TCP

An attacker intercepts: "Oh, the encrypted message is 1234. Let me decrypt it."

Step 3: Why the Attacker Can't Decrypt

The attacker sees:

  • C = 1234 (the ciphertext)
  • n = 3233 (Bob's public number)
  • e = 17 (the public exponent)

To decrypt, they need to compute:

M = C^d mod n
M = 1234^d mod 3233

But they don't know d. To find it, they need:

d = e^-1 mod φ(n)
d = 17^-1 mod 3120

Which requires knowing φ(n), which requires factoring n:

3233 = p × q = ?

Here's the critical point:

For 3233 (a small 12-bit number), factoring is trivial—it's just 61 × 53. Any human with a calculator can do it in seconds.

But for real RSA with 2048-bit numbers (617 digits), factoring is computationally impossible:

  • The number would be approximately 1.2 × 10^185
  • The fastest supercomputers would take thousands of years
  • No known algorithm can do it faster

The attacker is stuck. They can see the encrypted message, but they cannot decrypt it without knowing d, and they cannot know d without factoring a 2048-bit number, which is mathematically infeasible.

Step 4: Decryption by Bob (Who Knows the Secret)

Bob receives: C = 1234

Bob uses his private key (which only he knows):

d = 2753 (the secret exponent)

M = C^d mod n
M = 1234^2753 mod 3233
M = 1819  (the original message!)

Bob decrypts: 1819 = "HELLO"

The magic is that this works perfectly. The mathematics guarantees that only someone with d can decrypt. And d can only be calculated if you know p and q, which can only be obtained by factoring n—something an attacker cannot do.

Visual Journey: From Plain to Encrypted to Decrypted

Here's the complete flow:

ALICE'S SIDE (Sender):

Plaintext: "HELLO" (1819)
    ↓
Get Bob's PUBLIC key
Bob's Public Key: (n=3233, e=17)
    ↓
Encryption: 1819^17 mod 3233 = 1234
    ↓
SEND "1234" over UNENCRYPTED INTERNET

NETWORK (Insecure Channel):

Ciphertext: 1234
    ↓ (Attacker sees this)
    ↓ (Cannot decrypt this)

BOB'S SIDE (Receiver):

Received Ciphertext: 1234
    ↓
Use PRIVATE key - locked in vault
Bob's Private Key: (n=3233, d=2753)
← ONLY BOB KNOWS THIS
    ↓
Decryption: 1234^2753 mod 3233 = 1819
    ↓
Plaintext: "HELLO" (1819)
✓ Successfully decrypted!

Why This is Secure: The Asymmetry

The term "asymmetric" refers to the asymmetry of effort:

Encryption (anyone can do):

  • Public key is public
  • Takes seconds
  • No secret needed

Decryption (only Bob can do):

  • Private key is private
  • Takes seconds for Bob
  • Impossible for attackers (factoring is mathematically hard)

The Beautiful Asymmetry:

  • Encryption is easy with public key
  • Decryption is easy with private key
  • Decryption is hard without private key (mathematically hard, not just practically hard)

This is the entire concept of asymmetric encryption. The asymmetry is not in the keys themselves, but in what you can do with them. Bob has a secret trap door (the private key) that makes decryption trivial. Without this trap door, decryption is impossible.

Real-World Scale: Why 2048 Bits?

Let's understand why key size matters:

3-digit number (100-1000):        Easy to factor
4-digit number (1000-10000):      Easy to factor
5-digit number (10000-100000):    Easy to factor (seconds)
6-digit number:                   Easy to factor (seconds)
...
617-digit number (2048 bits):     ~1.2 × 10^185
                                   Would take longest supercomputer
                                   thousands of years to factor

The security doesn't come from secrecy—it comes from mathematical infeasibility.

The key size grows exponentially in difficulty. A 1024-bit RSA key (309 digits) is considered breakable with enough computing power. A 2048-bit key (617 digits) is considered secure until around 2030. A 4096-bit key is secure well into the future.

The Complete Picture: Hybrid Encryption

In practice, asymmetric encryption is slow. When you encrypt a 100MB file using RSA, you need to perform huge modular exponentiations for every block of data. This would take hours. Real-world systems solve this by using a hybrid approach that combines both asymmetric and symmetric encryption.

How the Hybrid Approach Works

The hybrid encryption method works as follows:

Step 1: Alice generates a symmetric key

Alice generates a random 256-bit AES key. This is just a random number, typically 32 bytes of random data. Let's call it KEY = xyz. This key will be used to encrypt the entire 100MB message with AES, which is fast.

Step 2: Alice encrypts the actual message with AES

Now Alice takes her 100MB message and encrypts it using the AES algorithm with the key she just generated. This operation is extremely fast—AES is optimized and can encrypt gigabytes per second on modern processors. The result is an encrypted 100MB file. AES is a symmetric cipher, so anyone with the key can decrypt it, but without the key it's secure.

Step 3: Alice encrypts the AES key with Bob's public key

Here's where RSA comes in. Alice cannot send the AES key in plaintext because an attacker could intercept it. Instead, she encrypts just the tiny 256-bit key using RSA with Bob's public key. Even though RSA is slow, it only needs to encrypt a small 256-bit value, not the entire 100MB file. This operation takes only milliseconds.

Step 4: Alice sends both over the insecure internet

Alice now sends two things to Bob:

  • The 100MB encrypted message (encrypted with AES)
  • The tiny encrypted AES key (encrypted with RSA, typically just a few hundred bytes)

Both travel over the public internet. An attacker can intercept both. But here's the security: the attacker cannot decrypt either one.

Step 5: Bob decrypts with his private key

When Bob receives both files, he:

  1. First uses his private RSA key to decrypt the AES key. Only Bob has this private key, so only he can recover the original KEY = xyz
  2. Then uses that recovered AES key to decrypt the 100MB message

The result: Alice's original message is recovered perfectly, and the entire process was both secure and fast.

Why Hybrid Encryption is Necessary

RSA's Problem: Speed

RSA is mathematically secure because factoring is hard. But it's also computationally expensive. When you encrypt with RSA, you're doing modular exponentiation: C = M^e mod n. With the huge 2048-bit numbers used in practice, this calculation takes time. For a single 256-bit AES key, it takes milliseconds. But for 100MB of data, you would need to apply RSA thousands of times (splitting the data into chunks, since RSA can only encrypt small amounts at a time). The total time would be hours.

AES's Problem: Key Distribution

AES is extremely fast and is the industry standard for symmetric encryption. A modern CPU can encrypt gigabytes per second with AES. But AES has a fundamental weakness: both parties need to know the same key. If Alice and Bob haven't met in person to exchange a key, they need to send it over the network. But the network is insecure. If Alice sends the AES key in plaintext, an attacker intercepts it. Now the attacker has the key and can decrypt all future messages. This is the chicken-and-egg problem: you need a secure channel to establish security, but you don't have one yet.

The Hybrid Solution

The hybrid approach solves both problems:

  • Use RSA to securely transfer the AES key. RSA's asymmetric nature solves the key exchange problem. Alice gets Bob's public key (which is safe to share) and encrypts just the 256-bit key. This takes milliseconds.
  • Use AES to encrypt the actual data. AES is blazingly fast for large files. The 100MB file encrypts in milliseconds.

Total time: milliseconds for the key exchange plus milliseconds for the data encryption. Total security: both RSA's security and AES's security.

Comparison:

ApproachSpeedSecurityProblem
RSA OnlyHours for 100MBSecure, asymmetricImpractical for large data
AES OnlyMillisecondsSymmetric, fastKey exchange problem - chicken and egg
HybridMilliseconds totalSecure + fastNone! Solves both problems

Why Combine Them?

RSA solves the fundamental problem of establishing a secure channel without having one already. The public key can be freely shared. Alice encrypts the AES key with Bob's public key, and only Bob can decrypt it with his private key. But RSA is too slow for large data.

AES is built for speed. Modern processors have hardware acceleration for AES. It can encrypt at gigabytes-per-second speeds. But AES requires that both parties already know the symmetric key. This is why it's perfect for the second part of the hybrid approach—by the time Alice and Bob use AES, they've already established the shared AES key through the RSA handshake.

Real-World Example: HTTPS Handshake

This hybrid approach is exactly what happens when you visit a secure website:

  1. Your browser connects to the server and requests the website
  2. The server sends its certificate containing an RSA public key (or ECDSA in modern systems)
  3. Your browser generates a random session key (like the AES key in our example)
  4. Your browser encrypts that session key with the server's public key using RSA
  5. Your browser sends the encrypted session key to the server
  6. The server decrypts it with its private RSA key, recovering the session key
  7. From that point on, all data is encrypted with AES using the session key
  8. The entire rest of the HTTPS connection uses AES (symmetric) encryption

This is why HTTPS is secure AND fast. The RSA/ECDSA handles the difficult key exchange problem, and AES handles the high-speed data encryption.

This same pattern is used in modern security protocols everywhere:

  • TLS/SSL (HTTPS websites)
  • Signal encrypted messaging
  • PGP/GPG email encryption
  • WhatsApp end-to-end encryption
  • Bitcoin and cryptocurrency transactions

The hybrid approach is the foundation of modern cryptography. It combines the best properties of both types of encryption: asymmetric encryption's ability to establish secure communication without prior shared secrets, and symmetric encryption's speed.

Digital Signatures: Encryption in Reverse

Asymmetric encryption also enables digital signatures, which prove who sent a message:

How it works:

Bob wants to PROVE he sent a message:

1. Bob creates message M = "I approve this transaction"

2. Bob ENCRYPTS with his PRIVATE key (only he can do):
   S = M^d mod n  (signature)

3. Bob sends: Message M + Signature S (both public)

4. Alice DECRYPTS with Bob's PUBLIC key:
   M' = S^e mod n

5. If M' == M, then:
   ✓ It came from Bob (only he has the private key)
   ✓ It hasn't been tampered with (cryptographic proof)
   ✓ Bob can't deny sending it (non-repudiation)

This is mathematically signed and verified. The beautiful thing is that Bob is using his keys backwards: he's encrypting with his private key and others are decrypting with his public key. This proves authenticity because only Bob has the private key. If someone tries to forge Bob's signature, they would need Bob's private key, which they don't have.

Why Unencrypted Channel = Still Secure

This is the key insight of asymmetric encryption:

The attacker knows:

  • Ciphertext C
  • Public exponent e
  • Modulus n
  • Bob's entire public key

The attacker cannot compute:

  • Private exponent d (requires factoring n)
  • Message M (requires d)
  • Anything meaningful

The security lies in mathematical impossibility, NOT in secrecy of transmission.

This is the fundamental insight. We're not hiding the message by keeping the channel secret. The message is sent in the open. The security comes from the mathematical fact that you cannot reverse the encryption without the private key, and you cannot derive the private key from the public key in feasible time.

Traditional encryption relies on secrecy: "If nobody knows the key, the message stays secret." Asymmetric encryption relies on mathematics: "Even if everybody knows the encryption key, the message stays secret because the decryption key is mathematically infeasible to derive."

The Weaknesses and Future

Current Vulnerabilities

1. Key Size Assumptions:

  • Current RSA-2048 is mathematically hard to break
  • But quantum computers could factor quickly
  • Post-quantum cryptography is being developed

2. Implementation Issues:

  • Weak random number generation can leak the private key
  • Side-channel attacks can reveal information through timing or power consumption
  • Improper key storage allows attackers to steal the private key
  • The encryption algorithm is secure, but mistakes in implementation can break security

3. Human Factor:

  • Public key must actually be authentic (certificate validation)
  • Man-in-the-middle attacks (attacker replaces Bob's public key)
  • Users must trust the certificate authority

Protection Against MITM (Man-in-the-Middle)

Without verification:

Alice thinks she has Bob's key, but gets attacker's key
    ↓
Alice encrypts message with attacker's key
    ↓
Attacker decrypts (has their own private key)
    ↓
Attacker re-encrypts with Bob's real public key
    ↓
Bob receives message (doesn't know attacker read it)
    ↓
Complete compromise - attacker read everything

Solution: Certificate Authorities

Trusted third party (Certificate Authority) signs keys
    ↓
Digital certificates verify key ownership
    ↓
Public Key Infrastructure (PKI) maintains trust chain
    ↓
Alice verifies Bob's key is authentic
    ↓
Man-in-the-middle attack prevented

Certificate authorities are organizations that verify someone's identity and then digitally sign their public key. When you visit an HTTPS website, your browser checks the certificate to verify it's really from the company it claims to be from. The certificate authority has vouched for the connection between the domain name and the public key.

Summary: The Magic Explained

Asymmetric encryption is not magic—it's elegant mathematics:

The core components:

  1. Key Generation creates a mathematical trap door

    • Two large primes multiplied together create n
    • Factoring n back to the primes is impossible
    • The private key d can only be computed knowing the primes
  2. Public Key is the easy direction (encrypt)

    • Anyone can use it
    • Encryption: C = M^e mod n
    • Takes seconds
  3. Private Key is the trap door (decrypt)

    • Only the holder knows it
    • Decryption: M = C^d mod n
    • Takes seconds for the holder
    • Impossible for others (factoring is hard)
  4. Security comes from one-way function difficulty

    • The factoring problem has no efficient solution
    • The security grows exponentially with key size
    • The security is mathematical, not practical
  5. Unencrypted channels are safe because eavesdroppers can't reverse the math

    • The message is sent openly
    • But reversing the encryption is mathematically infeasible
    • Security comes from mathematics, not channel secrecy
  6. Hybrid systems combine asymmetric (secure key exchange) with symmetric (fast data encryption)

    • RSA for bootstrapping security without prior secrets
    • AES for fast encryption of large data
    • Together they solve all the problems

The fundamental insight:

A problem can be easy to solve if you know the secret, but hard to solve if you don't—and this asymmetry can be mathematical. Not based on practical limitations or keeping secrets, but on the fundamental properties of mathematics. This is why asymmetric encryption works even when everyone knows the encryption key. The decryption key is mathematically infeasible to derive.

Conclusion

Asymmetric encryption solves the impossible-looking problem of secure communication over insecure channels by leveraging mathematical one-way functions. The beauty lies not in hiding the message—it's sent in the open—but in making it mathematically impossible to read without the private key.

Understanding this deep principle helps you appreciate why HTTPS works, why code signing is trustworthy, and why public keys can be freely shared. The security isn't about secrecy of transmission; it's about mathematical certainty. You can shout your encryption key from the rooftops, and the security remains—because the security comes from mathematics, not from secrecy.

This is the elegance of asymmetric encryption: it takes an impossible problem (secure communication without pre-established secrets) and makes it trivial through clever mathematics.

Sources and References

The concepts in this article are based on foundational cryptography research and standards widely used in production security systems:

RSA Encryption (Rivest-Shamir-Adleman):

  • Original paper: Rivest, R. L., Shamir, A., & Adleman, L. (1978). "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems." Communications of the ACM, 21(2), 120-126.
  • NIST/FIPS 186-4: Digital Signature Standard
  • RFC 8017: PKCS #1 - RSA Cryptography Specifications (Internet Engineering Task Force)

AES (Advanced Encryption Standard):

  • FIPS 197: Specification for the Advanced Encryption Standard
  • Federal Information Processing Standards Publication 197, National Institute of Standards and Technology, November 2001

Hybrid Encryption (TLS/SSL):

  • RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
  • RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
  • Used in HTTPS connections and modern web security

Factoring Complexity (One-Way Functions):

  • Lenstra, A. K., & Verheul, E. R. (2001). "Selecting Cryptographic Key Sizes." Journal of Cryptology, 14(4), 255-293.
  • Current RSA-2048 recommendations: https://www.keylength.com/ (tracks recommended key lengths)

Digital Signatures and Certificate Authorities:

  • X.509: Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 5280)
  • How PKI works in practice with certificate authorities

Man-in-the-Middle Prevention:

  • Certificate Pinning specifications
  • HPKP (HTTP Public Key Pinning) - RFC 7469
  • Real-world MITM attack examples and how PKI prevents them

Practical Applications Referenced:

  • HTTPS/TLS: Used by every secure website
  • PGP/GPG (RFC 4880): OpenPGP Message Format - used for email encryption
  • Signal Protocol: Documentation at https://signal.org/docs/ - end-to-end encrypted messaging
  • Bitcoin: Uses ECDSA (elliptic curve variant of asymmetric encryption)

These standards, protocols, and implementations are in use by billions of devices and systems worldwide. They have been extensively reviewed, tested, and vetted by the cryptography and security community. The mathematics described in this article is not theoretical—it powers the security infrastructure of the internet.