Encryption is the process of scrambling readable information — called plaintext — into an unreadable form called ciphertext, using a mathematical procedure (an algorithm) and a secret value (a key). Only someone holding the correct key can reverse the process, a step called decryption, and get the original information back.

Think of it like a locked diary. Anyone can pick up the diary and flip through its pages, but the writing inside means nothing without the key that unlocks the lock — or, in the digital world, without the cryptographic key that reverses the scrambling. Encryption does not stop someone from seeing your data; it stops them from understanding it.

Every time you check a bank balance, send a WhatsApp message, tap a payment card, or load a website with the little padlock icon in the address bar, encryption is running quietly in the background. It is one of the few technologies that almost every person on Earth relies on daily without realising it — and it is the reason our modern digital economy is possible at all.

Encryption is far older than computers. People have hidden the meaning of messages for over two thousand years, and each era’s tricks laid groundwork for the next — from wooden rods and shifted alphabets to the mathematics that now protects every website on Earth.

2.1 Ancient Beginnings

Around the 5th century BC, Spartan generals used a device called a scytale — a strip of parchment wound around a wooden rod. The message only made sense when the reader wrapped the same strip around a rod of the same width, otherwise the letters appeared as meaningless scattered characters.

Centuries later, Julius Caesar used a substitution technique — now called the Caesar cipher — where each letter in a message is swapped for a letter a fixed number of positions further down the alphabet. It was simple, but effective enough for Roman military use, and it remained unbroken for roughly eight centuries until an Arab mathematician worked out how to crack it using letter-frequency analysis, arguably the first documented act of “cryptanalysis” in history.

2.2 The Machine Age

By the early 20th century, mechanical rotor machines took over. An early rotor machine from the 1910s was among the first devices to automate substitution ciphers using rotating wired disks, an idea that would later inspire the German Enigma machine used in World War II. Breaking Enigma — most famously by Alan Turing’s team at Bletchley Park — is widely considered one of the events that gave birth to modern computing, because the machines built to crack Enigma directly influenced the design of the first electronic computers.

2.3 The Digital Era

Once computers arrived, encryption became a branch of mathematics rather than mechanics. In 1977, IBM’s DES (Data Encryption Standard) became the first publicly available, government-endorsed cipher. Its 56-bit key eventually became too short to resist brute-force attacks — a machine called “Deep Crack” publicly broke DES in under 24 hours in 1998. In 2001, the U.S. National Institute of Standards and Technology (NIST) replaced it with the Advanced Encryption Standard (AES), which remains the world’s dominant symmetric cipher today.

In parallel, 1976 brought a conceptual revolution: Whitfield Diffie and Martin Hellman showed that two people could agree on a shared secret over an insecure channel without ever meeting in person — the birth of public-key (asymmetric) cryptography, which RSA turned into a practical algorithm in 1977. This one insight is what makes modern e-commerce, secure messaging, and the entire HTTPS web possible, because it solved the previously impossible problem of “how do two strangers exchange a secret in front of an audience?”

Before going further, it helps to fix a shared vocabulary. These are the building blocks every encryption discussion rests on, and getting them straight up front prevents most of the confusion that later shows up in code reviews, incident reports and design docs.

At a mechanical level, every encryption scheme follows the same basic pattern, whether it is a Roman shift cipher scratched onto a wax tablet or AES-256 running on modern server hardware: take plaintext, combine it with a key using an algorithm, and produce ciphertext that can only be reversed by someone with the matching key.

Modern algorithms like AES do not just shift letters — they run the data through many rounds of substitution, permutation, and mixing with the key, so that even a single flipped bit in the input produces a completely different, unpredictable ciphertext. This property is called the avalanche effect, and it is essential for security: it prevents attackers from spotting patterns between similar messages, and it means an attacker cannot make small, targeted guesses about the plaintext by observing small changes in the ciphertext.

4.1 Block Ciphers vs. Stream Ciphers

Symmetric algorithms come in two structural flavours worth naming here. A block cipher like AES encrypts data in fixed-size chunks (128 bits at a time for AES); if a message does not fit exactly, it is padded to the next block boundary. A stream cipher like ChaCha20 generates a continuous keystream of pseudo-random bits from the key and XORs it byte-by-byte with the plaintext, which makes it particularly efficient for streaming media, VoIP calls and mobile connections where data arrives one packet at a time. Both families are considered secure when used correctly with modern algorithms; the choice usually comes down to whether the workload is bulk chunks or a continuous stream.

Nearly every modern cipher falls into one of two families, and understanding the difference is the single most important idea in this guide — almost every other decision in cryptography flows from it.

5.1 Why Both Exist

Symmetric encryption is fast but faces a chicken-and-egg problem: how do you securely share the secret key with the other party before you have any secure channel to share it over? Asymmetric encryption solves that exact problem elegantly, but it is far too slow to encrypt megabytes of data at wire speed. The natural answer — used everywhere from HTTPS to Signal — is to combine them, which we will look at in detail in the Hybrid Encryption section.

The Advanced Encryption Standard (AES) is a symmetric block cipher adopted by NIST in 2001, and it remains the backbone of modern data security — used in HTTPS, Wi-Fi (WPA2/WPA3), VPNs, disk encryption, and end-to-end messaging apps. If you have opened a padlocked website today, AES was almost certainly the workhorse that carried your data.

AES processes data in fixed 128-bit blocks and comes in three key sizes, each running a different number of transformation “rounds” of substitution and mixing. More rounds mean more thorough diffusion of the key into the ciphertext, which is why the higher-security variants also do more work per block:

A 128-bit key alone has roughly 3.4 × 10³⁸ possible combinations — a number so large that even a supercomputer trying billions of keys per second would need far longer than the age of the universe to brute-force it. This is why, when AES is implemented correctly, real-world attacks target weak key management, weak random-number generation, or protocol-level mistakes rather than the underlying math itself — the math is not the weak point.

6.1 Modes of Operation, Briefly

A “mode of operation” wraps around the raw block cipher and defines how successive blocks are chained together to encrypt a message longer than a single block. Modern deployments overwhelmingly favour AES-GCM (Galois/Counter Mode) and, in some hardware-constrained settings, AES-XTS (for disk encryption). Both provide authenticated encryption, meaning any tampering with the ciphertext is detected at decryption time rather than silently producing corrupted plaintext, which was a subtle but real weakness of older modes like CBC when used without a separate MAC.

Asymmetric cryptography is where public-key mathematics turns into practical software. Two schemes dominate the modern landscape: RSA, the classical choice, and Elliptic Curve Cryptography, the modern efficient alternative.

RSA (named after its inventors Rivest, Shamir, and Adleman) generates a linked pair of keys from the product of two very large prime numbers. Data locked with the public key can only be opened with the matching private key, and vice versa. Its security rests on the fact that multiplying two huge primes together is easy, but factoring the result back into those primes is, with today’s computers, practically impossible — a problem no algorithm has ever solved in reasonable time for sufficiently large numbers.

Elliptic Curve Cryptography (ECC) achieves the same security guarantees using a completely different branch of mathematics — the algebra of points on an elliptic curve — and needs far shorter keys to do it. A 256-bit ECC key offers security roughly equivalent to a 3072-bit RSA key, which matters enormously for mobile devices, IoT sensors, and anywhere battery life, bandwidth or storage is limited. Shorter keys also mean smaller certificates and faster handshakes, which is why almost every new deployment now defaults to ECC rather than RSA.

Because asymmetric math is computationally expensive, it is rarely used to encrypt large amounts of data directly. Instead, it plays a narrower, more critical role: proving identity through digital signatures, and safely agreeing on a temporary shared secret that a fast symmetric cipher can then use for the actual data. That combination — asymmetric for setup, symmetric for bulk — is the pattern behind almost every secure protocol on the internet, and it is the subject of the Hybrid Encryption chapter later in this guide.

7.1 Digital Signatures

Asymmetric keys have a beautiful second application beyond confidentiality: digital signatures. Signing data with your private key produces a small blob anyone with your public key can verify came from you and has not been altered. This is what lets your browser trust that a website really is the site it claims to be, what proves a piece of software has not been tampered with since the vendor built it, and what backs mechanisms like passkeys and hardware security keys. Encryption and signing use the same underlying mathematics but solve different problems: encryption is about “only they can read it,” and signing is about “anyone can verify I wrote it.”

People frequently confuse encryption with hashing, but they solve different problems — and mixing them up is behind a startling number of real security incidents. Getting this distinction clear early saves a great deal of trouble later.

When a website “encrypts your password,” it almost never actually does — it hashes it (typically with a slow, salted algorithm like bcrypt or Argon2) and stores only the hash. When you log in, the site hashes what you typed and compares the two hashes; the original password is never stored or recoverable, even by the company itself. This is exactly why a well-run service can honestly tell users “we cannot recover your password — we can only let you reset it,” and it is the reason a database breach at such a service is embarrassing but not automatically catastrophic.

8.1 Salted Hashing for Passwords

A plain hash of “password123” is always the same value across every database that hashes it the same way, which is why attackers precompute enormous rainbow tables to instantly look up common hashes. Adding a unique salt — a random per-user value hashed together with the password — makes every stored hash unique even for identical passwords, and neutralises rainbow tables entirely. Modern password-hashing schemes like Argon2 do this automatically and also make each individual hash deliberately expensive to compute, so that even offline brute-forcing becomes economically painful for an attacker.

Almost every secure system on the internet — including the padlock icon in your browser — is a hybrid of both families: asymmetric encryption to safely exchange a temporary key, and symmetric encryption to do the heavy lifting on the actual data. This is the specific engineering trick that makes the entire modern web possible.

This design is called Perfect Forward Secrecy: because a fresh session key is generated for every connection and then discarded, even if an attacker steals the server’s long-term private key tomorrow, they still cannot decrypt today’s captured traffic. Over 98% of enterprise web traffic now runs on TLS 1.3, which enforces this model by default and has fully retired the older, weaker key-exchange methods that lacked forward secrecy.

9.1 Certificates and Chains of Trust

The TLS handshake also solves a subtle problem: how does your browser know the “public key” it just received actually belongs to the real website and not an impostor sitting in the middle of the connection? The answer is certificates — small signed documents issued by a trusted Certificate Authority (CA) that bind a public key to a specific domain name. Your browser ships with a hard-coded list of trusted CAs, and it verifies the chain of signatures from the site’s certificate back up to one of those roots. Only if the chain is intact, unexpired, and matches the domain you actually typed does the padlock appear. This mechanism is what stops an attacker on public Wi-Fi from silently pretending to be your bank — they cannot mint a valid certificate for a domain they do not own.

Here is a minimal, production-safe pattern for encrypting data with AES-256 in GCM mode, which provides both confidentiality and tamper detection in a single operation.

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import java.security.SecureRandom;

public class AesGcmExample {

    public static byte[] encrypt(byte[] plaintext, SecretKey key, byte[] iv) throws Exception {
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        GCMParameterSpec spec = new GCMParameterSpec(128, iv); // 128-bit auth tag
        cipher.init(Cipher.ENCRYPT_MODE, key, spec);
        return cipher.doFinal(plaintext);
    }

    public static SecretKey generateKey() throws Exception {
        KeyGenerator keyGen = KeyGenerator.getInstance("AES");
        keyGen.init(256, new SecureRandom());
        return keyGen.generateKey();
    }
}

10.1 What This Example Deliberately Skips

Real production code around this snippet would also need to safely load the key from a secrets manager (not generate one every run), attach any “additional authenticated data” (like a record ID) so GCM binds the ciphertext to its context, and package the IV together with the ciphertext in a stable format so the decryption side always knows where each part starts. Every one of those concerns is where subtle bugs creep in when developers first roll their own encryption code, which is exactly why higher-level libraries such as Google Tink and libsodium wrap the raw primitives shown above in safer, harder-to-misuse APIs. In practice, unless there is a very specific reason not to, reach for one of those libraries before hand-rolling the pattern above.

Encryption algorithms are rarely the weak point in a real system — poor key management almost always is. A stolen or leaked key defeats even the strongest cipher instantly, which is why the discipline of “key management” is often bigger and more organisationally sensitive than the choice of algorithm itself.

11.1 Envelope Encryption

A widely used real-world pattern for large systems is envelope encryption: instead of encrypting every record with the master key directly, each record (or each customer, or each file) gets its own data key, and the master key only ever encrypts those data keys. The data keys travel with the ciphertext in encrypted form; only the master key, held in a KMS or HSM, can unwrap them. This limits blast radius (a leaked data key only exposes one record), makes rotation cheap (rotating the master re-wraps the data keys, without touching the underlying encrypted data), and keeps the crown-jewel master key away from the systems that actually process traffic. Almost every major cloud KMS is designed around this pattern.

Encryption is not a single feature bolted onto one part of a system — it protects data at three fundamentally different phases of its life, and each phase brings its own trade-offs and tooling.

12.5 A Layered View

A modern application typically uses encryption in several of these phases simultaneously: TLS protects the request from browser to server; the server writes the record into a database whose storage is encrypted at rest; sensitive columns like credit card numbers may be individually encrypted with envelope encryption; automated backups are themselves encrypted before leaving the primary account; and any long-lived tokens the user holds are signed with an asymmetric key so a stolen token cannot be forged. No single one of these layers is sufficient by itself — together they form what security engineers call defence in depth, where an attacker who breaks through one layer still faces the next one.

Even correct algorithms can be defeated by clever attacks against the surrounding implementation. Recognising these patterns is what separates a “we use AES” system from a genuinely secure one.

13.1 Padding-Oracle and Similar Protocol Attacks

A whole category of real-world breaks against older protocols — the padding-oracle attacks that defeated SSL 3.0 (POODLE), the Bleichenbacher attacks against certain RSA padding schemes, and the BEAST and CRIME attacks against early TLS — came not from a broken cipher but from tiny information leaks in the surrounding protocol: how long a response took, whether an error message appeared, exactly which byte the server rejected. Modern authenticated modes and modern TLS versions were specifically designed to remove those leaks, which is a major reason older TLS versions have been aggressively deprecated.

The performance gap between symmetric and asymmetric encryption is not a minor implementation detail — it is a direct consequence of the underlying math, and it shapes every real-world protocol.

Symmetric ciphers operate on data using bitwise operations that map efficiently onto CPU instructions (many modern CPUs even have dedicated AES hardware acceleration, called AES-NI, that can encrypt gigabytes per second per core). Asymmetric operations involve large-number modular exponentiation, which is inherently far more expensive — often thousands of times slower, per byte, than symmetric encryption on the same hardware.

This is precisely why hybrid encryption exists: use the slow, expensive asymmetric operation once per session to exchange a key, then let a fast symmetric cipher handle the actual data at wire speed. Any protocol that tried to encrypt every byte of every request with RSA would collapse under its own overhead long before it reached production scale.

14.1 Practical Throughput Numbers

On modern server hardware with AES-NI enabled, AES-256-GCM comfortably reaches several gigabytes per second per core — effectively free relative to the network and disk speeds it usually sits behind. RSA-2048 signing, by comparison, tops out at a few thousand operations per second per core, and RSA decryption is even slower. ChaCha20-Poly1305 was designed specifically to run fast on mobile devices without hardware AES acceleration and is often the default on such platforms for exactly that reason. These numbers matter because they explain why some architectural choices — putting a TLS-terminating load balancer in front of many application servers, for instance — make dramatic differences to overall system capacity.

Quantum computers, if they become powerful enough, would reshape which cryptography is safe — and unlike most technology transitions, this one has to be started long before the threat actually arrives.

A future quantum computer would run an algorithm called Shor’s Algorithm that can factor large numbers and solve the elliptic-curve discrete logarithm problem exponentially faster than classical computers — potentially breaking RSA and ECC entirely. AES is much less at risk, since the best-known quantum attack against it (Grover’s Algorithm) only halves its effective key strength, so AES-256 stays comfortably secure with an effective 128 bits of quantum-resistant security.

NIST guidance has flagged that quantum computers capable of this kind of attack could plausibly arrive by around 2030, often nicknamed “Q-Day.” In response, NIST finalised new post-quantum cryptography standards — including ML-KEM (based on lattice math, formerly known as Kyber) — designed to resist both classical and quantum attacks. Organisations handling long-lived sensitive data are already beginning “harvest now, decrypt later” risk assessments and migration planning, since data encrypted today could be captured and stored by an adversary for decryption once quantum computers mature.

15.1 What Migration Looks Like in Practice

The migration is not a single overnight cutover. Real systems will pass through a hybrid phase where connections are protected by both a classical (ECDHE) and a post-quantum (ML-KEM) key exchange in parallel — only breakable if both are broken. Several major browsers and cloud providers already offer this hybrid mode experimentally, and CDNs like Cloudflare have publicly reported enabling it for a significant portion of connections. This mirrors how earlier cryptographic transitions actually worked in practice: SHA-1 to SHA-2, TLS 1.0 to 1.3, and so on — all rolled out gradually with overlap rather than as sudden switches.

A short, opinionated checklist. If a code review turns up any of the anti-patterns on the right, treat it as an incident-in-waiting rather than a cosmetic issue.

Every one of the ideas above shows up in production systems most people use daily, often without noticing. Seeing the same pattern in five different real products is what makes the theory feel concrete.

A few of the questions that come up most often when engineers first work seriously with encryption, followed by the ideas from this guide worth remembering.

No. A password is a way to prove your identity; encryption is a mathematical process that scrambles data. Passwords are often used to derive an encryption key (through a slow key-derivation function like Argon2 or PBKDF2), but the password itself is not the key and they are not interchangeable concepts.

Properly implemented modern encryption like AES-256 cannot realistically be brute-forced with any technology that exists or is on the horizon. Real-world breaches almost always come from stolen keys, weak passwords, software bugs, side channels, or social engineering — not from breaking the math itself. In other words, the algorithm is almost never the weakest link.

They solve different problems. Asymmetric encryption solves the hard problem of exchanging a secret safely with someone you have never met, and of proving identity through signatures; symmetric encryption solves the problem of encrypting large amounts of data quickly. Using both together — hybrid encryption — gets the best of both, which is exactly what every modern secure protocol does.

Not entirely. Quantum computers threaten RSA and ECC specifically, because those rest on mathematical problems (integer factoring and elliptic-curve discrete logarithms) that Shor’s Algorithm can attack. Symmetric ciphers like AES remain largely safe, and new post-quantum algorithms are already being standardised and rolled out to replace at-risk asymmetric schemes. The migration is a decade-long project rather than a cliff edge.

No, but you do need to respect a small set of hard rules: use standard algorithms in standard modes, never invent your own scheme, generate keys with a proper source of randomness, never reuse an IV with the same key, and protect the keys themselves at least as carefully as the data they lock. Following those rules using a reputable, well-maintained library gets you the vast majority of the security benefit without needing to understand the underlying number theory.