How Modern Encryption Works: From Caesar Cipher to AES-256 and Post-Quantum Cryptography

Every time you sign in to a website, send a private message, make an online payment, connect to a VPN, or upload confidential data to the cloud, cryptography is working in the background.

The basic objective sounds simple: turn readable information into something an unauthorized person cannot understand.

Modern cryptography, however, does much more than scramble text.

A secure system may need to provide:

• Confidentiality so outsiders cannot read the data
• Integrity so unauthorized changes can be detected
• Authentication so parties can verify who they are communicating with
• Secure key establishment over an untrusted network
• Digital signatures to verify data or software
• Protection for stored information as well as information moving across networks

Understanding how we reached modern systems such as AES, public-key cryptography, TLS 1.3, and post-quantum cryptography is easier if we begin with one of the simplest ciphers ever taught: the Caesar cipher.

What Is Encryption?

Encryption transforms readable information, called plaintext, into an unintelligible form called ciphertext using a cryptographic algorithm and usually a key.

Decryption performs the reverse operation.

In simplified form:

Plaintext + Key
      ↓
Encryption Algorithm
      ↓
Ciphertext

The authorized recipient uses the appropriate key and algorithm to recover the original information:

Ciphertext + Key
       ↓
Decryption Algorithm
       ↓
Plaintext

NIST defines encryption as the cryptographic transformation of plaintext into ciphertext in order to conceal its original meaning.

Modern security depends heavily on one additional principle:

The algorithm should not need to be secret. The security should primarily depend on protecting the key.

That is very different from merely hiding how a system works.

Caesar Cipher: A Simple Starting Point

The Caesar cipher is a classical substitution cipher traditionally associated with Julius Caesar.

Its idea is straightforward: shift every letter by a fixed number of positions in the alphabet.

Suppose the shift key is 3:

A → D
B → E
C → F
...
X → A
Y → B
Z → C

The word:

HELLO

becomes:

KHOOR

To decrypt it, the recipient shifts each letter three positions in the opposite direction.

Why Caesar Cipher Is Easy to Break

The English alphabet contains 26 letters, so a Caesar-style rotation has only 26 possible shifts if the no-change shift is included—and only 25 nontrivial alternatives.

An attacker does not need sophisticated mathematics.

They can simply try every possibility.

Key 1 → ...
Key 2 → ...
Key 3 → KHOOR → HELLO
...

This is called a brute-force attack: testing possible keys until one produces meaningful plaintext.

That illustrates one of the most important ideas in cryptography:

Key Space Matters

The key space is the total number of possible keys an attacker may have to consider.

A small key space can often be searched.

A sufficiently large one cannot realistically be exhausted.

But simply increasing the number of shifts does not turn a classical cipher into modern cryptography.

From Simple Substitution to More Complex Ciphers

Later classical systems improved on fixed substitution by changing how individual characters were transformed.

Polyalphabetic techniques, for example, can use different substitutions at different positions instead of shifting every character identically.

This dramatically expands the number of possible configurations.

But these systems still have weaknesses.

Repeated keys, language patterns, letter frequencies, and statistical relationships can leak information that allows cryptanalysis without testing every theoretical key.

That is an important lesson:

A large-looking key space does not automatically make an encryption algorithm secure.

Modern cryptography therefore depends on extensively analyzed mathematical constructions rather than simply making old substitution schemes more complicated.

What Does a 256-Bit Encryption Key Mean?

A bit has two possible values:

0
1

A one-bit key has:

2¹ = 2

possible values.

An eight-bit key has:

2⁸ = 256

possible values.

A 128-bit key has:

2¹²⁸ ≈ 3.4 × 10³⁸

possibilities.

A 256-bit key has:

2²⁵⁶ ≈ 1.16 × 10⁷⁷

possible values.

The difference between 128 and 256 bits is therefore not merely "twice as many keys."

The search space increases exponentially.

AES-256 and Modern Symmetric Encryption

The Advanced Encryption Standard, or AES, is one of the most important symmetric encryption standards in modern computing.

NIST's AES standard defines three supported key lengths:

AES operates on 128-bit data blocks regardless of which supported key size is used.

This corrects a common oversimplification: 256-bit encryption is not the single universal standard required for every secure application.

AES-128, AES-192, and AES-256 are standardized options.

The appropriate choice depends on the system, security requirements, protocol, implementation, and threat model.

How Large Is the AES-256 Key Space?

AES-256 has approximately:

1.16 × 10⁷⁷

possible keys. NIST gives the same approximate scale for the 256-bit AES key space.

Consider an intentionally unrealistic brute-force example.

Suppose attackers had 100,000 machines and every machine could somehow test:

10¹⁵ keys per second

The combined rate would be:

10²⁰ keys per second

Searching the entire 256-bit space at that rate would still take roughly:

3.7 × 10⁴⁹ years

This example is not intended as a realistic benchmark for attacking AES. It simply demonstrates the scale of a 256-bit key space.

Key Length Is Not the Whole Security Story

A 256-bit key cannot rescue a badly designed system.

Real encryption security also depends on:

• Secure random key generation
• Correct encryption modes
• Proper nonce or IV handling
• Key storage
• Key rotation
• Authentication
• Software implementation
• Access control
• Endpoint security

An attacker will often target a stolen key, vulnerable server, exposed credential, bad implementation, or compromised endpoint rather than attempting to enumerate 2²⁵⁶ keys.

This is why cryptography and cybersecurity are related but not interchangeable.

Symmetric Encryption Explained

Symmetric cryptography uses the same secret—or closely related secret keying material—for encryption and decryption.

Conceptually:

Sender
  │
Shared Secret Key
  │
Encrypt
  ↓
Ciphertext
  ↓
Decrypt
  │
Same Shared Secret
  ↓
Receiver

AES is symmetric.

Advantages of Symmetric Encryption

Symmetric encryption is generally well suited to protecting large quantities of data.

Common applications include:

• Network traffic
• Storage encryption
• Database encryption
• Backups
• VPN traffic
• Application data

The difficult part is often not encrypting the data.

It is securely establishing and managing the secret key.

The Key Distribution Problem

Imagine Alice and Bob want to communicate securely across a network controlled by attackers.

If they already share a strong secret key, they can use symmetric encryption.

But how do they exchange that secret in the first place?

Sending it unprotected creates an obvious problem:

Alice → Secret key → Internet → Bob
                    ↑
                 Attacker

If an attacker captures the key, the encrypted communication may no longer be confidential.

This key distribution problem is one reason public-key cryptography became so important.

What Is Asymmetric Encryption?

Asymmetric, or public-key, cryptography uses mathematically related keys instead of requiring both parties to begin with the same secret.

Typically there is:

• A public key that can be distributed
• A private key that must remain secret

A simple educational analogy is a locked mailbox.

Anyone can place a message inside the mailbox.

Only the person holding the private opening key can retrieve what is inside.

That analogy helps explain one function of public-key cryptography, but it can also create a misleading picture of how modern internet encryption works.

Web browsers do not normally use public-key operations to encrypt every byte of an HTTPS session.

Modern protocols use a hybrid approach.

Symmetric vs Asymmetric Cryptography

Neither approach replaces the other.

Modern protocols combine them.

How Modern HTTPS Encryption Actually Works

HTTPS uses TLS — Transport Layer Security.

TLS establishes a protected channel between applications communicating over a network.

As of 2026, TLS 1.3 remains the current protocol version. In July 2026, the IETF published RFC 9846, a backward-compatible update to the original TLS 1.3 specification in RFC 8446. The updated specification tightens several requirements while retaining TLS 1.3 as the protocol version.

A simplified TLS session looks like this:

Browser                          Server
   │                               │
   │──── ClientHello ─────────────>│
   │                               │
   │<──── Server parameters ───────│
   │       + key material          │
   │       + authentication        │
   │                               │
   │   Establish shared secrets    │
   │<─────────────────────────────>│
   │                               │
   │==== Symmetric encryption =====│
   │==== Application traffic ======│

The handshake establishes cryptographic parameters and shared secret keying material.

Afterward, the communicating endpoints use the resulting traffic keys to protect application data.

This is the key idea:

Public-key techniques help establish trust and shared secrets. Fast symmetric cryptography protects the bulk data.

Modern Encryption Must Protect Integrity Too

Confidentiality alone is not enough.

Suppose an attacker cannot understand your encrypted message but can modify ciphertext in a way that changes the resulting data.

That is still dangerous.

Modern protocols therefore commonly use authenticated encryption.

TLS 1.3 requires Authenticated Encryption with Associated Data, or AEAD, for protecting records. The mechanism provides both confidentiality and integrity protection.

Common AEAD constructions used in modern protocols include AES-GCM and ChaCha20-Poly1305.

This means the recipient can determine not only whether outsiders could read the message, but whether protected data was altered.

Encryption, Hashing, and Digital Signatures Are Different

These concepts are often incorrectly grouped together.

They solve different problems.

Passwords Usually Should Not Be "Encrypted"

Passwords are a good example.

A properly designed authentication system generally does not need to recover a user's original password.

Instead, password verifiers should store appropriately salted password hashes designed to resist offline guessing attacks.

Current NIST digital identity guidance explicitly requires suitable salted password hashing for password storage.

That distinction matters:

Sensitive document → Encryption may be appropriate

User password → Password hashing should generally be used

What Digital Signatures Do

Digital signatures solve a different problem from encryption.

They can help establish that:

1. Data came from the expected signer.
2. The signed data has not been modified after signing.

For example, digital signatures can be used with:

• Software releases
• Certificates
• Documents
• API messages
• Firmware
• Cryptographic protocols

A digital signature does not necessarily hide the signed content.

Its core purpose is authenticity and integrity.

Does HTTPS Mean a Website Is Trustworthy?

No.

HTTPS means that the connection between your client and the authenticated endpoint can be protected using TLS.

It does not prove that:

• The company is honest
• The product is legitimate
• The website contains accurate information
• A seller will fulfill an order
• The service itself is safe

A malicious website can also use HTTPS.

Transport security protects the connection.

It does not certify the intentions of the organization operating the endpoint.

Encryption at Rest vs Encryption in Transit

Encryption also needs to be considered according to where the information exists.

Encryption in Transit

Protects information moving across networks.

Examples include:

• HTTPS/TLS
• VPN connections
• Secure APIs
• Encrypted messaging protocols

Encryption at Rest

Protects stored information.

Examples include:

• Encrypted disks
• Encrypted databases
• Backups
• Cloud storage
• Encrypted files

A mature security architecture may require both.

Protecting network traffic does little good if attackers can simply steal an unencrypted database from the server.

Transport Encryption vs End-to-End Encryption

These concepts are also different.

With standard transport encryption, data may be encrypted between individual network endpoints but become readable inside the service processing it.

With properly designed end-to-end encryption, the intermediate service should not possess the keys necessary to read message content.

A simplified comparison:

Transport encryption:

User ==== encrypted ==== Server
                         ↓
                    Server can process
                    plaintext

End-to-end encryption:

User A ================= User B
          ciphertext

Intermediate service does not possess
the content-decryption key

Whether end-to-end encryption is appropriate depends on the application.

Why Key Management Can Be Harder Than Encryption

AES itself is not usually the difficult part of building a secure system.

Protecting cryptographic keys is.

A production system has to consider:

• Who can access keys?
• Where are keys stored?
• How are keys generated?
• How are they backed up?
• When should they rotate?
• What happens if one is compromised?
• Can old data still be decrypted?
• Who can revoke a key?
• Are keys separated by environment or purpose?

NIST maintains detailed guidance specifically for cryptographic key management because these operational controls directly affect the security of encrypted information.

A perfectly strong algorithm paired with a publicly exposed private key is not a secure system.

Will Quantum Computers Break Encryption?

This question needs a careful answer because "encryption" covers several very different cryptographic techniques.

Large, cryptographically relevant quantum computers could significantly affect many current public-key systems.

NIST specifically identifies RSA and elliptic-curve cryptography as examples of current public-key approaches threatened by sufficiently capable quantum computers.

Symmetric encryption has a different risk profile.

What About AES?

Grover's algorithm can theoretically provide a quadratic speedup for generic key search on a sufficiently capable quantum computer.

That does not mean AES-256 suddenly becomes easy to crack.

NIST states that current applications can continue using AES with 128-, 192-, or 256-bit keys and notes practical limitations that reduce the apparent advantage of applying Grover's algorithm to real-world brute-force attacks.

So the post-quantum migration challenge is not simply:

Replace AES-256.

A major immediate focus is replacing quantum-vulnerable public-key techniques used for key establishment and digital signatures.

Post-Quantum Cryptography Is Already Here

Post-quantum cryptography, or PQC, is designed to run on conventional computers while resisting attacks from both classical and quantum computers.

This is no longer just experimental research.

NIST published its first three finalized post-quantum cryptographic standards in August 2024:

• FIPS 203 — ML-KEM, for key establishment
• FIPS 204 — ML-DSA, for digital signatures
• FIPS 205 — SLH-DSA, a stateless hash-based digital signature standard

NIST now recommends that organizations begin applying the standards and planning migration to quantum-resistant cryptography.

What Is ML-KEM?

ML-KEM is a Key Encapsulation Mechanism.

Its purpose is to allow two parties to establish shared secret keying material across a public channel.

That secret can then be used with symmetric cryptography to protect communications.

NIST standardized three ML-KEM parameter sets:

• ML-KEM-512
• ML-KEM-768
• ML-KEM-1024

They represent different security and performance trade-offs.

Notice how the architecture still resembles the hybrid cryptography model used today:

Post-quantum key establishment
            ↓
      Shared secret
            ↓
   Symmetric encryption
            ↓
       Protected data

Post-quantum cryptography does not eliminate symmetric encryption.

It changes important parts of how secure secrets and signatures can be established.

"Harvest Now, Decrypt Later" Changes the Timeline

A common mistake is assuming organizations only need to prepare for post-quantum cryptography after powerful quantum computers exist.

An adversary could potentially capture encrypted information today and retain it in the hope that future technology enables decryption.

For information that needs to remain confidential for many years, migration planning therefore matters before the threat fully materializes.

NIST's current guidance tells organizations to begin transitioning, and its published migration direction targets moving away from quantum-vulnerable cryptography over the coming years, with high-risk systems transitioning earlier.

Crypto Agility Is Becoming a Security Requirement

Organizations learned an important lesson from previous cryptographic transitions:

Replacing algorithms across a large infrastructure can be extremely difficult.

Cryptography may be embedded inside:

• Applications
• APIs
• Hardware
• Firmware
• Databases
• Certificates
• VPNs
• Identity systems
• Cloud infrastructure
• Third-party libraries
• Network appliances

That has made crypto agility increasingly important.

Crypto agility means designing systems so algorithms, protocols, keys, and cryptographic implementations can be replaced without rebuilding the entire technology stack.

NIST updated its crypto-agility guidance in June 2026, emphasizing the operational ability to adapt cryptographic algorithms across software, hardware, protocols, and infrastructure while maintaining security and availability.

For engineering teams, that means avoiding unnecessarily hard-coded cryptographic dependencies.

Common Encryption Mistakes

1. Building Your Own Cryptographic Algorithm

Creating a cipher that looks difficult to understand is not the same as creating a secure cryptosystem.

Use established, extensively analyzed cryptographic libraries and standards.

2. Hard-Coding Keys Into Source Code

A strong AES key committed to a public repository is no longer a strong secret.

Use appropriate secret-management or key-management infrastructure.

3. Reusing Nonces Incorrectly

Some encryption modes have strict nonce or IV requirements.

Incorrect reuse can seriously weaken security.

4. Encrypting Without Authentication

Confidentiality alone may not detect ciphertext manipulation.

Prefer appropriate authenticated-encryption constructions where applicable.

5. Using Encryption for Password Storage

Use suitable password-hashing mechanisms rather than reversible encryption for ordinary password verification.

6. Assuming Longer Keys Fix Everything

AES-256 cannot compensate for:

• Stolen credentials
• Malware
• SQL injection
• Misconfigured cloud storage
• Exposed API keys
• Vulnerable dependencies
• Broken authorization

Cryptography is one security layer.

7. Ignoring Algorithm Migration

Today's approved algorithm may eventually need replacement.

Build systems that can evolve.

A More Accurate Mental Model of Modern Internet Security

Instead of thinking:

Public key
   ↓
Encrypt everything
   ↓
Internet

think:

Identity / authentication
        +
Secure key establishment
        ↓
Shared session secrets
        ↓
Authenticated symmetric encryption
        ↓
Protected application traffic

And as the ecosystem transitions toward post-quantum security:

Classical / Post-Quantum
Key Establishment
        ↓
Shared Secret
        ↓
Symmetric Traffic Keys
        ↓
AES / other approved AEAD
        ↓
Protected Communication

That model is much closer to how real secure protocols are engineered.

Frequently Asked Questions

Is AES-256 unbreakable?

No cryptographic algorithm should be described as absolutely unbreakable.

However, exhaustive classical brute-force search of a correctly generated 256-bit AES key is computationally infeasible with existing technology.

Real-world attacks are more likely to target implementations, endpoints, credentials, keys, or surrounding systems.

Is AES-128 still secure?

NIST continues to standardize AES-128, AES-192, and AES-256 and states that current applications can continue using these key sizes.

The appropriate option depends on the application and security requirements.

Is RSA the same as AES?

No.

AES is symmetric encryption.

RSA is a public-key cryptographic system that can be used for specific public-key operations.

Modern TLS does not simply replace AES with RSA. Different cryptographic primitives perform different roles.

Does TLS 1.3 use AES-256?

TLS 1.3 supports authenticated symmetric cipher suites, including AES-based options, but AES-256 is not mandatory for every connection.

The client and server negotiate supported cryptographic parameters according to the protocol.

Is SSL still used?

"SSL" is still commonly used in product names and casual conversation, but modern secure web communication uses TLS.

For current systems, TLS is the relevant protocol family.

Does HTTPS encrypt everything about my browsing?

No.

TLS protects application data between the communicating endpoints, but encrypted connections do not necessarily hide every observable property of communication, such as all traffic metadata or packet lengths.

The current TLS specification explicitly notes that confidentiality does not inherently hide transmitted data length, although padding mechanisms can reduce some forms of traffic analysis.

Can quantum computers break AES-256?

Known quantum techniques affect symmetric and asymmetric cryptography differently.

NIST does not currently recommend abandoning AES-256 because of quantum computing. Its current guidance states that AES-128, AES-192, and AES-256 can continue to be used while quantum-resistant public-key migration proceeds.

What encryption should developers use?

There is no single algorithm that fits every application.

Developers should normally rely on mature cryptographic libraries, secure protocols, platform APIs, and recognized standards rather than designing their own cryptography.

The correct design depends on whether the goal is protecting data in transit, data at rest, credentials, messages, signatures, keys, or some combination of them.

From Caesar Cipher to Crypto Agility

The journey from Caesar's cipher to modern cryptography is not simply a story of making keys longer.

It is a progression in how we think about trust.

Caesar's cipher teaches the basic concept of transforming plaintext.

Modern symmetric encryption demonstrates the power of enormous key spaces and carefully analyzed algorithms.

Public-key cryptography addresses authentication and secure key establishment across untrusted networks.

TLS combines several cryptographic primitives into a practical protocol for protecting internet communication.

Authenticated encryption protects both confidentiality and integrity.

Password hashing solves a different problem entirely.

And post-quantum cryptography is now preparing critical public-key infrastructure for threats that existing RSA- and elliptic-curve-based systems were not designed to withstand.

The next major challenge is therefore not merely finding an even bigger number than 256.

It is building systems that can change cryptography safely when the threat landscape changes.

That is why post-quantum migration and crypto agility have become important engineering priorities in 2026.

Strong cryptography is not one cipher, one key length, or one protocol.

It is an architecture of carefully selected algorithms, secure key management, correct implementation, authentication, integrity protection, operational controls, and the ability to evolve.