All posts
encryptionfundamentalssecurity

What Is Encryption? A Visual, Interactive Guide

From Caesar ciphers to AES-256 and public-key cryptography — an interactive walkthrough of how encryption works, why it matters, and what makes modern crypto unbreakable.

E

Encra Team

Engineering

4 min read988 words

You use encryption dozens of times a day without thinking about it. Every time you open a banking app, send a message, or buy something online, cryptography is silently protecting your data. But what is it actually doing?

This guide starts from zero and builds up to modern public-key cryptography. No math degree required — just curiosity.

The core idea: scrambling data so only the right person can unscramble it

Encryption transforms readable data (called plaintext) into unreadable gibberish (called ciphertext) using a rule. Only someone who knows the rule — or the key — can reverse it.

The simplest example: the Caesar cipher. Shift every letter forward by 3. "HELLO" becomes "KHOOR". To decrypt: shift back by 3.

Plaintext:   H E L L O
Shift +3:    K H O O R
Ciphertext:  KHOOR

This is terrible encryption — there are only 25 possible shifts, and anyone can try them all in seconds. But it illustrates the concept: a key (the shift amount) transforms readable text into ciphertext.

Modern encryption uses the same idea, just with mathematics so complex that trying all possible keys would take longer than the age of the universe.

Symmetric encryption: one key for both sides

The simplest modern approach uses the same key to encrypt and decrypt. This is called symmetric encryption.

The most widely used algorithm is AES (Advanced Encryption Standard). AES-256 uses a 256-bit key — that's 2^256 possible keys. Trying them all at 1 trillion keys per second would take ~10^60 years. The universe is ~14 billion years old.

Try it yourself — this is real AES-256-GCM encryption running in your browser:

Live Encryption Sandbox — AES-256-GCM
1Generate a secret key

Click to generate a random 256-bit AES key

2Enter plaintext
3Encrypt

Notice a few things from the demo:

  • The same key encrypts and decrypts
  • The ciphertext looks completely random — no trace of the original
  • The nonce (IV) is unique per encryption — encrypting the same text twice gives different ciphertext
  • Without the key, you cannot decrypt

The key management problem

Symmetric encryption has one fatal weakness: both sides need the same key. If Alice wants to encrypt a file for Bob, she needs to somehow get the key to Bob first.

But if she sends the key over the internet, an attacker could intercept it. If she hands it over in person, that's expensive and doesn't scale to millions of users.

This is the key distribution problem. It stumped cryptographers for decades.

Asymmetric encryption: the public/private key revolution

In 1976, Whitfield Diffie and Martin Hellman proposed something radical: what if you could establish a shared secret over an insecure channel, without ever transmitting the secret itself?

The insight is beautiful. Here's the visual intuition:

Interactive: Diffie-Hellman Key Exchange

Shared public color

Alice and Bob agree on a public paint color. Anyone can see this — it doesn't need to be secret.

Alice
public
Public coloreveryone sees
Bob
public
Step 1 / 5

The color-mixing analogy captures the key insight of Diffie-Hellman key exchange:

  • Mixing colors in one direction is easy (forward)
  • "Unmixing" colors is computationally infeasible (backward)
  • Real DH uses modular exponentiation: g^(a+b) mod p — you can compute it forward, but reversing it (the discrete logarithm problem) is believed to be computationally intractable

In practice, modern systems use X25519 (Elliptic Curve Diffie-Hellman over Curve25519), which is what Encra uses. It's faster and has stronger security properties than original DH.

Public keys and private keys

From key exchange comes the idea of a key pair:

  • Public key: share this freely. Anyone can encrypt data for you with it.
  • Private key: never share this. Only you can decrypt data encrypted with your public key.

This solves the key distribution problem entirely:

  1. You publish your public key (post it on your website, register it with a service)
  2. Anyone can encrypt a message for you using your public key
  3. Only you can decrypt it — with your private key that never left your device
Alice wants to message Bob:

1. Alice fetches Bob's public key (safe to transmit)
2. Alice encrypts: encrypt(message, bob_public_key) → ciphertext
3. Bob decrypts: decrypt(ciphertext, bob_private_key) → message

An interceptor has the ciphertext and Bob's public key.
They cannot decrypt — private key is required, and it never left Bob's device.

Hybrid encryption: combining both worlds

Asymmetric encryption is slower than symmetric encryption — sometimes 1000x slower. So in practice, systems use both:

  1. Use asymmetric encryption (Diffie-Hellman) to establish a shared secret key between two parties
  2. Use symmetric encryption (AES) to encrypt the actual data with that shared key

This is how TLS (HTTPS), Signal, WhatsApp, and Encra all work:

Session Setup:        Diffie-Hellman key exchange → shared secret
Data Transfer:        AES-GCM encryption with the shared secret

You get the convenience of asymmetric key exchange (no pre-shared secret needed) and the speed of symmetric encryption for the actual data.

What makes modern encryption "unbreakable"?

Three things:

1. Key size — A 256-bit key has 2^256 possible values. Brute-forcing it is physically impossible with classical computers.

2. One-way functions — Operations like modular exponentiation and elliptic curve multiplication are easy to compute forward but believed to be intractable in reverse. There is no known efficient algorithm to reverse them.

3. Semantic security — Modern algorithms like AES-GCM produce different ciphertext every time (via random nonces), so an attacker can't detect patterns even if they see many encryptions of the same message.

Encryption is only as strong as the implementation

Cryptographic algorithms are secure. Implementations are not always. The most common vulnerabilities are: reusing nonces (IVs), storing keys insecurely, using weak key derivation, or trusting the wrong certificate. This is why "use a well-audited library, don't roll your own crypto" is the cardinal rule.

What Encra adds on top

Standard HTTPS encryption protects data in transit — from your browser to the server. But the server decrypts it. The server sees everything.

Encra adds end-to-end encryption: messages are encrypted on the sender's device and decrypted only on the recipient's device. The server relays encrypted ciphertext it can never read.

It also adds forward secrecy: even if a device is compromised today, past messages are safe because the keys used to encrypt them have already been deleted. This is done through the Double Ratchet algorithm — which we cover in the next article.


Encra is free during beta. Get a key at encra.dev/signup — no credit card required.