DEV Community: Anurag Jain

Decoding Cryptography: From Perfect Secrecy to Computational Security

Anurag Jain — Thu, 09 Jul 2026 14:32:42 +0000

(Lion Roaring)…

In Blog 1, I set up Alice, Bob, and the postman. In the last blog, I broke three historical ciphers, watched the postman evolve from barbarian to statistician to pattern hunter, and arrived at three pillars of modern cryptography: formal definitions, precise assumptions, and rigorous proofs.

I ended with a mathematical definition that looked like this:

∀ m0, m1 ∈ M, ∀ c ∈ C: Pr[C = c | M = m0] = Pr[C = c | M = m1]

I'd promised to explain what this means, build something that achieves it, and then show why even that isn't enough.

More math incoming, I said. I wasn't kidding.

Computation Theory Primer

In math, vague words cause vague security, and vague security is no security at all.

Before I can define what "perfect" security means, I need three precise concepts. Think of them as the grammar we'll write the rest of modern cryptography in.

The Security Parameter

Imagine your encryption system has one master control: how hard it is to break. Crank it up, and the system becomes more secure, but also slower. Crank it down, and it's faster but weaker.

This control has a name: the security parameter, denoted n.

In symmetric encryption, n is typically the key length in bits (128, 256, etc). Once we fix n, everything becomes a function of it:

The running time of Gen, Enc, Dec
The running time of any adversarial algorithm
The probability that an adversary breaks the scheme

By expressing everything as a function of n, we can talk about how quantities grow as we scale, rather than arguing about specific numbers. A question like "is this cipher secure?" becomes "does security hold for all sufficiently large n?"

Efficient Algorithms

Not all algorithms are created equal. An algorithm that takes n² steps is fine. One that takes n¹⁰ steps is annoying but feasible. One that takes 2ⁿ steps? For n = 256, that's too much.

An algorithm A is efficient (or polynomial-time) if there exists a polynomial p(·) such that for every input x, A terminates within p(|x|) steps, where |x| is the size of the input.

Polynomial: n², n³, n¹⁰. Superpolynomial: 2ⁿ, n!, nⁿ. The gap between these two worlds is the difference between efficient and inefficient.

Why does this matter? It gives us a sanity requirement on any encryption scheme.

Gen, Enc, and Dec must all run in polynomial time in n.

If decryption takes 2ⁿ steps, even Bob can't read his own messages. Not useful.

Pause. So far: n is the dial, polynomial time is "efficient". One more concept to go.

Negligible Functions

Intuitively, a negligible quantity is one that is "so small, we can safely ignore it." But how small is that? Smaller than 1/1000? Smaller than 1/10²⁰? Those are concrete numbers. But negligible is a comparative term.

What I want is something that shrinks faster than the inverse of any polynomial.

A function f(n) is negligible if ∀ positive polynomials p(n), ∃ N such that ∀ n > N:

f(n) < 1/p(n)

Equivalently, ∀ positive constants c, ∃ N such that ∀ n > N, f(n) < n^−c.

(These are equivalent because any polynomial p(n) is eventually dominated by n^c for some c. So "smaller than 1/p(n) for every polynomial" means the same as "smaller than n^-c for every constant c".)

The key observation: no polynomial function is ever negligible, no matter how large the exponent. But exponential (and sub-exponential) decay is negligible. There's a hard divide between these worlds.

A concrete sanity check. Take f(n) = 2⁻ⁿ. For any polynomial p(n) = n^d, choose N = 2d. Then for all n > N:

2⁻ⁿ < 2^{−d log2 n} = n^−d = 1/p(n)

So 2⁻ⁿ is indeed negligible. ✓

Let's build some intuition.

Function	Negligible?	Why
2⁻ⁿ	✓ Yes	Shrinks exponentially, easily beats any 1/p(n)
2^−√n	✓ Yes	Slower, but still eventually beats every polynomial inverse
n⁻¹⁰⁰⁰	✗ No	It is 1/p(n) for p(n) = n¹⁰⁰⁰. It can't be less than 1/n¹⁰⁰¹ for all large n

Why is n⁻¹⁰ not negligible? Pause on this, it's the most common mistake. The definition demands f(n) < 1/p(n) for every polynomial p. Pick p(n) = n¹¹. Then 1/p(n) = n⁻¹¹. Is n⁻¹⁰ < n⁻¹¹ for all large n? No, n⁻¹⁰ > n⁻¹¹ always. So it fails the definition.

Okay, enough definitions for now. Let's see why cryptographers actually care about these properties.

Why These Two Concepts Work Together

Here's the key insight: negligible functions behave exactly the way we'd hope when combined. Adding two negligible quantities doesn't suddenly make them significant. And multiplying a negligible quantity by something that grows polynomially still gives you something negligible.

Formally, if negl1(n) and negl2(n) are negligible, then the following holds.

negl1(n) + negl2(n) is negligible

p(n) · negl1(n) is negligible, for any polynomial p(n)

And if p1(n) and p2(n) are polynomial, then:

p1(n) + p2(n) is polynomial

p1(n) · p2(n) is polynomial

(Both negligible properties can be proved by contradiction. Assume the result is not negligible ⇒ there exists a polynomial it doesn't eventually go below ⇒ one of the originals wasn't negligible either. Contradiction.)

The second negligible property is the one I want you to remember. It means there is no amplification of a negligible advantage.

Here's a vivid way to see it. Toss n fair coins. The probability of all heads is (1/2)ⁿ = 2⁻ⁿ, which is negligible. Now repeat this experiment p(n) times, say n² times. What's the probability that at least one trial gives all heads?

Pr[∃ success in n² trials] ≤ n² · 2⁻ⁿ

(This is an upper bound via the union bound, not necessarily equality — two trials could both succeed on the same outcome.) By the closure property, n² · 2⁻ⁿ is still negligible. You could run the experiment a polynomial number of times and still have a negligible chance of the rare event occurring.

For cryptography, this implies that if an adversary's advantage in one attack is negligible, running the attack polynomially many times doesn't help. Attempts don't compound into a real threat.

Good. We have our vocabulary: efficient means polynomial time, negligible means shrinks faster than any inverse polynomial, and these two concepts compose cleanly. Now let's use them.

Perfect Secrecy

At the end of the last blog, I sketched a requirement. The ciphertext distribution should be completely independent of which message was encrypted. Now I can state this formally.

What Can Be Perfect?

What would it mean for a cipher to be truly, perfectly, unbreakably secure? Not "hard to break." Not "would take a million years." Not "probably safe." But perfectly secure, where the ciphertext reveals absolutely nothing about the plaintext, no matter how much time and computation the adversary has.

This is not a philosophical question. It has a precise mathematical answer, and it was given by Claude Shannon in 1949.

Shannon's Definition

Definition (Perfect Secrecy): An encryption scheme (Gen, Enc, Dec) over message space M has perfect secrecy if for every probability distribution over M, for every pair of messages m0, m1 ∈ M, and for every ciphertext c ∈ C with Pr[C = c] > 0:

Pr[C = c | M = m0] = Pr[C = c | M = m1]

Read it aloud. The probability that ciphertext c was produced, given that the plaintext was m0, equals the probability that c was produced given the plaintext was m1. For any two messages and any ciphertext.

The distribution of the ciphertext is independent of the underlying plaintext. Observing c gives the adversary zero additional information about which message was encrypted.

The adversary (our postman, with unlimited time, unlimited computing power, unlimited cleverness) stares at the ciphertext and learns absolutely nothing. Not a single bit of information. This is the strongest possible notion of secrecy.

An Equivalent View

There is another way to read the same definition, and this form is closer to the intuition behind the reference. It says that the ciphertext distribution is independent of the plaintext distribution. Once the attacker sees c, nothing about the message has become more likely than before. In probability language, the posterior belief about the plaintext is unchanged by the ciphertext.

Equivalently, for every message m and every ciphertext c with non-zero probability,

Pr[M = m | C = c] = Pr[M = m]

This is the same idea expressed from the other side. The ciphertext does not update the attacker's belief at all. That is what perfect secrecy really means. The attacker may see the whole ciphertext, but the mathematics says the ciphertext carries no information about which plaintext was sent.

Beautiful definition. But can anything actually achieve it?

The One-Time Pad

The Perfect Mask

Before I build a perfectly secure cipher, I need one basic operation. Let's start with a single bit b (either 0 or 1). I want to apply a "mask" bit that could hide that bit or leave it as it is.

b' = b masked with mask

b	mask	b'
0	0	0
0	1	1
1	0	1
1	1	0

If the mask is 0, leave it alone. If the mask is 1, hide it. Another way to see it is that if both bits are the same, output 0 and if different, output 1.

Now here's the magic: masking is its own inverse.

(b masked with mask) masked with mask = b

Why? If mask = 0, nothing happened either time. If mask = 1, it flipped twice, right back to the original. Mask once to encrypt, mask again to decrypt. One can also observe that this mask is associative and commutative.

In computer science, we have a name for this exact operation. It is XOR (exclusive or, denoted ⊕).

For bit strings of length ℓ, XOR operates bit by bit.

(1, 0, 1, 1) ⊕ (0, 1, 1, 0) = (1, 1, 0, 1)

The Construction

The One-Time Pad (OTP), also called the Vernam cipher, is beautifully simple. The message space, key space, and ciphertext space are all ℓ-bit strings.

M = K = C = {0, 1}^ℓ

where ℓ is a publicly known system parameter. The scheme works as follows.

Gen(): Output a uniformly random key k ∈ {0, 1}^ℓ

Enc(m, k): Output c = m ⊕ k (bitwise XOR)

Dec(c, k): Output m = c ⊕ k (bitwise XOR)

That's it. Just XOR the message with a uniformly random key.

Note that Enc here is deterministic, meaning there's no internal randomness. All the randomness comes from Gen, which produces the key. This is fine as long as the key is used only once (I'll show why shortly).

Correctness

From Blog 1, the correctness requirement is that Dec(Enc(m, k), k) = m for every message m and every key k that Gen could output.

Dec(Enc(m, k), k) = Dec(m ⊕ k, k) = (m ⊕ k) ⊕ k = m ⊕ (k ⊕ k) = m ⊕ 0^ℓ = m ✓

XOR of k with itself is all zeros. XOR with all zeros is the identity. Done.

The Proof

Now the main event. I'll prove OTP achieves Shannon's definition of perfect secrecy.

Claim: ∀ m0, m1 ∈ {0, 1}^ℓ and ∀ c ∈ {0, 1}^ℓ:

Pr[C = c | M = m0] = Pr[C = c | M = m1]

Proof:

Fix an arbitrary plaintext m0 and an arbitrary ciphertext c. The encryption Enc(m0, k) = m0 ⊕ k produces c precisely when:

m0 ⊕ k = c ⇒ k = m0 ⊕ c

So the conditional probability is the following.

Pr[C = c | M = m0] = Pr[k = m0 ⊕ c]

Since Gen outputs k uniformly at random from {0, 1}^ℓ, the probability of any specific ℓ-bit string is as follows.

Pr[k = m0 ⊕ c] = 1/2^ℓ

Now do the exact same calculation for m1.

Pr[C = c | M = m1] = Pr[K = m1 ⊕ c] = 1/2^ℓ

Both probabilities equal 1/2^ℓ, regardless of what m0, m1, or c are. ▮

The postman stares at the ciphertext and is, mathematically, completely clueless. Every plaintext is equally likely to have produced any ciphertext. Perfect secrecy achieved. ^____^

Don't Strive for Perfection

The One-Time Pad is perfectly secure, yes. But it comes with two devastating limitations. And these aren't quirks of OTP, they're inherent to any perfectly secure cipher.

Limitation 1: The Key Must Be as Long as the Message

Theorem: If an encryption scheme (Gen, Enc, Dec) is perfectly secure, then |K| ≥ |M|.

The key space must be at least as large as the message space. This is not about OTP specifically — it's about any scheme that achieves perfect secrecy.

Proof (by contradiction):

Suppose, for contradiction, that our scheme is perfectly secure but |K| < |M|. Consider the uniform distribution over M, and fix a ciphertext c with Pr[C = c] > 0.

Define the set of all valid decryptions of c.

M(c) = {Dec(c, k) : k ∈ K}

Each key k gives exactly one decryption Dec(c, k), but two different keys might decrypt to the same message. So the set M(c) has at most |K| elements.

|M(c)| ≤ |K| < |M|

Since M(c) is strictly smaller than M, there exists some message m* ∈ M that is not in M(c). This means no key in K maps c back to m*:

Pr[C = c | M = m*] = 0

But m* has non-zero probability under the uniform distribution, so for any m ∈ M(c), Pr[C = c | M = m] > 0.

We got our contradiction.

Assertion -> If keys are x-bit strings and messages are y-bit strings:

|K| ≥ |M| ⇒ 2^x ≥ 2^y ⇒ x ≥ y

Want to encrypt a 1 GB file? You need a 1 GB key. Want to encrypt a 10 GB video call? You need a 10 GB key. And you had to somehow securely share that key beforehand, which was the entire problem we were trying to solve in the first place! (T_T)

Limitation 2: The Key Cannot Be Reused

For OTP specifically:

Suppose Alice reuses the same key k for two messages m0 and m1, producing c0 = m0 ⊕ k and c1 = m1 ⊕ k. The postman intercepts both and computes the following.

c0 ⊕ c1 = (m0 ⊕ k) ⊕ (m1 ⊕ k) = m0 ⊕ m1 ⊕ (k ⊕ k) = m0 ⊕ m1

The key cancels out. The postman now holds the XOR of the two plaintexts, a significant amount of information, especially if the messages are natural language text. Enough to begin recovering both.

As Turing Award winner Michael Rabin put it: "You should never reuse a one-time pad. It is like toilet paper. If you reuse it, things get messy."

For any perfectly secure cipher (proof sketch).

This isn't just an OTP problem. Suppose any perfectly secure cipher reuses key k for two messages m1 ≠ m2. Now consider the postman intercepting the pair of ciphertexts (c1, c2).

Perfect secrecy would require (c1, c2) to look identical whether the sender encrypted (m1, m1) or (m1, m2). But if c2 can be the encryption of both m1 and m2 under the same key k, then Dec(c2, k) would have to return two different answers. Decryption is a function — it can't. Contradiction.

So perfect secrecy with key reuse contradicts correctness. Each encryption must use an independently generated key. ▮

Need to chillax

Let's take stock of what perfect secrecy demands.

Requirement	Practical?
Key as long as the message	Encrypt a 1 GB file → share a 1 GB key first
Fresh key for every message	100 messages → share 100 independent keys

If Alice and Bob could securely share a 1 GB key for every message, they might as well share the 1 GB message directly.

And here's the thing: remember from Blog 2 that even the most powerful supercomputers can't exceed about 10²⁰ (roughly 2⁶⁷) operations per second. The postman, formidable as he is, has neither unlimited computation nor unlimited time. So why am I defending against an infinitely powerful adversary?

Perfect secrecy is the mathematical gold standard. But the gold standard is too expensive for everyday use.

The Birth of Computational Security

Here's the pivot. Instead of demanding that the adversary learns absolutely nothing, we make 2 concessions and in return, we get what we actually need. Short, reusable keys.

Why These Concessions Are Necessary

Consider any encryption scheme where the same key k is used for multiple messages. In the KPA model (from Blog 1), the adversary has a collection of (message, ciphertext) pairs encrypted under the same unknown k.

Two trivial attacks are unavoidable against any such scheme:

Attack 1: Brute-Force Key Recovery

The adversary tries every k' ∈ K. For each candidate, it checks whether Dec(ci, k') = mi for all known pairs. When it finds the right one, it has the key.

Property	Value
Running time	O(\|K\|), linear in the key space size
Success probability	1 (100%)

For |K| = 2²⁵⁶, this takes on the order of 2²⁵⁶ operations. At 10²⁰ operations per second, that's roughly 10⁵⁷ years. Not practical.

Attack 2: Guessing

The adversary picks a single random k' ∈ K and checks if it's correct.

Property	Value
Running time	O(1), constant, near instant
Success probability	1/\|K\|

For |K| = 2²⁵⁶, the success probability is 1/2²⁵⁶.

These two attacks represent extremes: one guarantees success but takes essentially forever; the other is instant but almost certainly fails.

We accept both realities and build the security model around them.

Relaxation 1 (Effort): We only require security against efficient (polynomial-time) adversaries.

Brute force succeeds with probability 1, but its running time is exponential in n, so it's not efficient. We declare: attacks that take superpolynomial time don't count.

Relaxation 2 (Chance): We allow the scheme to be broken with negligible probability.

Guessing works in O(1) time, but its success probability 1/2ⁿ is negligible. So we declare: attacks that succeed with only negligible probability don't count either.

Notice — the terms efficient and negligible are the ones I defined at the beginning of this blog. I was laying the groundwork for exactly this moment.

With these two relaxations, we arrive at computational security.

Computational Security: An encryption scheme is computationally secure if no efficient adversary can break it except with negligible probability.

Compare this with perfect secrecy.

	Perfect Secrecy	Computational Security
Adversary	Computationally unbounded	Computationally bounded (polynomial time)
Security guarantee	Adversary learns absolutely nothing	Adversary learns something with negligible probability

This is weaker than perfect secrecy. Given enough time, a computationally secure scheme can be broken. But the time required is so vast, and the probability of a shortcut so tiny, that for practical purposes, the scheme might as well be perfectly secure.

If the postman can't crack the letter in his lifetime, Alice and Bob's secret stays safe.

And the relaxation buys us two things we couldn't have before, which I'll formally prove in future blogs:

Short keys — a 128 or 256-bit key to encrypt arbitrarily long messages
Key reuse — the same key can be used for multiple messages

Choosing n: Where You Draw the Line

One final subtlety. These definitions are asymptotic, meaning they describe what happens as n → ∞. But in practice, you pick a concrete value of n and deploy the scheme. Choose poorly, and asymptotic security is worthless.

Imagine a cipher where any adversary running for n² steps succeeds with probability n⁵ · 2⁻ⁿ. Asymptotically, the success probability is negligible. Looks safe on paper.

But plug in concrete values.

n (key bits)	Adversary runtime	Success probability	Verdict
10	100 steps ≈ instant	10⁵ · 2⁻¹⁰ ≈ 97%	Completely broken
30	900 steps ≈ instant	30⁵ · 2⁻³⁰ ≈ 0.02%	Marginal
256	65536 steps ≈ instant	256⁵ · 2⁻²⁵⁶ ≈ 2⁻²¹⁶	GGs

At n = 10, an instant attack succeeds 97% of the time. At n = 256, that same attack succeeds with probability so small it makes the number of atoms in the universe look large.

This is exponential returns on security: each extra bit of n doubles the exponent in the denominator, so the safety gain accelerates as n grows. The first 10 bits bought almost nothing; bits 200–256 buy you astronomical safety.

The security parameter is where you draw that line. Push it right, and you pay more in running time (Gen, Enc, Dec all scale with poly(n)), but buy exponentially more safety. Pull it left, and operations are faster but you erode that margin. Choosing the right setting is an engineering decision — it requires understanding the concrete numbers, not just the asymptotic story.

What's Next?

To summarize what I did in this blog.

Built the vocabulary: the security parameter n, efficient algorithms (polynomial-time), and negligible functions (shrinks faster than any polynomial inverse)
Stated Shannon's perfect secrecy — the strongest possible notion of security
Proved the One-Time Pad achieves it
Proved two fundamental impossibilities inherent to any perfectly secure cipher: keys must be as long as messages, and no key can be reused
Modern cryptography didn't abandon perfect secrecy because it failed. It abandoned it because its costs outweigh its benefits for most applications.
Introduced computational security, the pragmatic bargain that trades perfection for practicality — secure against efficient adversaries, breakable only with negligible probability

But I haven't yet said what computational security looks like as a formal definition. What's the computational analogue of Shannon's perfect secrecy? How do I state it precisely, and, critically, how do I prove a scheme achieves it?

That's the next blog. I'll formalize computational indistinguishability, meet the first provably secure construction under a hardness assumption, and see the three principles of modern cryptography (define, assume, prove) in full action.

Acknowledgment

The technical content in this blog draws from "Introduction to Modern Cryptography (Second Edition)" by Jonathan Katz and Yehuda Lindell, and from Professor Ashish Choudhury's lecture series on Foundations of Cryptography.

So the next time someone offers you perfect security, ask them about the key length. If it's shorter than the message... well, you've read this blog. You know what Shannon would say.

Note: The mathematical formulations in this blog are simplified for readability. The proofs are faithful to the originals. The images and diagrams in this blog are AI-generated and meant to be illustrative, not precise technical specifications.

Decoding Cryptography: The Fall of Historical Ciphers

Anurag Jain — Thu, 09 Jul 2026 14:25:11 +0000

Previously, on "The Love Letter Problem"…

In the last blog, we met Alice and Bob, watched our nosy postman fail to crack their symmetric encryption, and laid down the formal syntax (Gen, Enc, Dec), Kerckhoffs' Principle, attack models, and a question: what does "secure" actually mean?

We left off with the promise of math. This blog delivers on that promise by breaking things.

We're going to look at three historical ciphers that people actually used for centuries. Each one seems clever. Each one gets destroyed. And the way they get destroyed teaches us exactly why modern cryptography needs mathematical rigor.

Note: We'll be using some basic number theory (modular arithmetic) in this blog. Don't Panic (Arthur Dent). I'll introduce everything as we go.

Modular Arithmetic 101

Before we break ciphers, we need one tool: modular arithmetic. I will use the famous example of "clock math" to explain.

If it's 10 o'clock and you wait 5 hours, it's 3 o'clock — not 15 o'clock (unless you, like me, love 24hr format). You "wrapped around" at 12. Modular arithmetic formalizes this wraparound.

We write:

a mod n = the remainder when a is divided by n

Some examples:

15 mod 12 = 3
29 mod 26 = 3
26 mod 26 = 0
7 mod 26 = 7

The general idea is that when you reach the end, you loop back to the beginning. We'll be working mod 26 a lot, because the English alphabet has 26 letters.

Letters as Numbers

To do math on letters, we need to turn them into numbers. The convention is simple:

a	b	c	d	e	f	g	h	i	j	k	l	m	n
0	1	2	3	4	5	6	7	8	9	10	11	12	13

o	p	q	r	s	t	u	v	w	x	y	z
14	15	16	17	18	19	20	21	22	23	24	25

So "h" is 7, "t" is 19, and so on. Alice, Bob, the postman, all know this mapping. It's just a way to talk about letters using numbers.

Cipher #1: The Shift Cipher (Caesar Cipher)

As the name suggests, it is believed to have been used by Julius Caesar. I will be using both the names to get you desensitized. The idea:

Pick a random number k between 0 and 25. To encrypt, shift every letter forward by k positions. To decrypt, shift back by k positions.

Let's write this down formally using the Gen, Enc, Dec syntax from blog 1:

Gen(): Pick k ∈ {0, 1, 2, …, 25} uniformly at random

Enc(m, k): ∀ character mi in the message, compute ci = (mi + k) mod 26

Dec(c, k): ∀ character ci in the ciphertext, compute mi = (ci − k) mod 26

Simple Example

Suppose k = 3 and Alice wants to encrypt "hello".

Plaintext	h	e	l	l	o
As number	7	4	11	11	14
+ k = 3	10	7	14	14	17
mod 26	10	7	14	14	17
Ciphertext	k	h	o	o	r

Alice sends "khoor" to Bob. Bob, who knows k = 3, subtracts 3 from each letter and recovers "hello".

The postman sees this and scratches his head. For now.

Breaking the Caesar Cipher: Brute Force

Now let's think like the postman. He intercepts "khoor" and wants to recover the message.

He knows it's a shift cipher (thanks again, Kerckhoffs). He doesn't know k yet. But k can only be one of 26 values: 0, 1, 2, …, 25. So he just tries them all:

Candidate k	Decryption of "khoor"
k = 0	khoor
k = 1	jgnnq
k = 2	ifmmp
k = 3	hello ← meaningful English!
k = 4	gdkkn
…	… (all gibberish)

26 attempts. A child could do this by hand. A computer does it in microseconds.

This is a brute force attack: exhaustive search over all k ∈ K. With |K| = 26, it's simple.

The Sufficient Key Space Principle

The shift cipher teaches us a fundamental lesson:

Sufficient Key Space Principle: Any secure cipher must have a key space large enough that a brute force attack is computationally infeasible.

This is a necessary condition, not sufficient. Large |K| doesn't guarantee security (as we'll see next), but small |K| guarantees insecurity. If the adversary can exhaustively search over all k ∈ K... you've already lost.

Let me clarify, how large is "large enough"?

To answer this, consider the power of modern computer. Supercomputers can't go more than 10²⁰ (I am taking some liberty with the numbers), that is about 2⁶⁷ operations per second.

Thus, a key space of at least 2⁸⁰ is considered the bare minimum, and modern ciphers like AES-256 use a key space of 2²⁵⁶, a number so large that if every atom in the observable universe were a computer trying a billion keys per second, they still wouldn't finish before the heat death of the universe.

A key space of 26 becomes a joke in comparison.

Cipher #2: The Mono-Alphabetic Substitution Cipher

Alright, so the postman broke the shift cipher because there were only 26 keys. What if we give him a lot more keys?

The idea: instead of shifting every letter by the same amount, we create a a permutation (which is a special kind of bijection, else Dec won't be deterministic ^^ ) from plaintext letters to ciphertext letters. Each letter maps to a different, unique letter.

For example, a possible key might be:

Plaintext	a	b	c	d	e	f	…	z
Ciphertext	q	w	z	r	x	b	…	m

Under this key, every "a" in the plaintext becomes "q", every "c" becomes "z", and so on. The receiver, who knows the same permutation, reverses it.

Formally:

Gen(): Pick a random permutation σ : {0,…,25} → {0,…,25}

Enc(m, σ): ∀ mi, compute ci = σ(mi)

Dec(c, σ): ∀ ci, compute mi = σ⁻¹(ci)

where σ⁻¹ is the inverse permutation (the mapping in reverse).

The Key Space: 26!

How many possible keys are there? A key is a permutation of 26 letters, and the number of permutations of 26 items is:

26! = 26 × 25 × 24 × … × 1 ≈ 4 × 10²⁶ ≈ 2⁸⁸

That's roughly 2⁸⁸. An astronomically larger key space than the shift cipher's 26 keys. A brute force attack would need to try about 2⁸⁸ permutations. Even with modern hardware, this is infeasible.

So we're safe, right? The sufficient key space principle is satisfied.

Not so fast.

Breaking the Substitution Cipher: Frequency Analysis

Remember that the sufficient key space principle is a necessary condition, not a sufficient one. A large key space protects against brute force, but who said brute force is the only attack?

The postman is evolving. For the shift cipher, brute strength was enough. Now he puts on his statistician hat (!!!). He knows something about English that no permutation can hide.

The Fingerprint of Language

Every natural language has statistical patterns. In English:

The letter "e" appears roughly 12.7% of the time
"t" appears about 9.1% of the time
"z" barely shows up at 0.07%

Here are the approximate frequencies of all English letters:

Letter	Frequency	Letter	Frequency
e	12.7%	s	6.3%
t	9.1%	h	6.1%
a	8.2%	r	6.0%
o	7.5%	d	4.3%
i	7.0%	l	4.0%
n	6.7%	…	…

And it goes beyond single letters. Common bigrams (pairs of letters) like "th", "he", "in" appear far more often than "qz" or "jx". Common trigrams like "the", "and", "ing" are also well-documented.

This is all public data. Anyone can compute these statistics from a large English corpus.

The Attack

By now, you must've enough hints to understand how to break the cipher. I will still mention the attack method for completeness.

Frequency map of every letter in ciphertext.
Compare it with the known English frequency chart.
Play Match the following.
Refine using bigram and trigram frequencies until the permutation is recovered.

For a long enough ciphertext, this works beautifully. No brute force needed. The permutation, all 26! possibilities, is cracked by exploiting the statistics of the English language.

The lesson: a large key space is necessary but not sufficient. The substitution cipher has 2⁸⁸ keys but falls to a simple statistical attack.

Cipher #3: The Vigenère Cipher

So the substitution cipher was broken because every "e" always maps to the same ciphertext letter. Alice and Bob are smart, but very stubborn. They still want to use shift and keep the ciphers somewhat simple.

Vigenère cipher (we've already heard of this. Also called the poly-alphabetic substitution cipher) enters the stage!! Instead of one shift applied uniformly, it uses a keyword of length t, and each letter of the keyword specifies a different shift.

Formally:

Gen(): Pick a random length t ≥ 1, then pick a random string k = (k1, k2, …, kt) where each kj ∈ {0, 1, …, 25}

Enc(m, k): Divide the message into blocks of length t. For each character mij (the j-th character of the i-th block), compute: cij = (mij + kj) mod 26

Dec(c, k): For each character cij, compute: mij = (cij − kj) mod 26

Notice the subscript on k: it's kj, not just k. The shift changes depending on the position within the block.

Example

Let the keyword be "cipher" (length t = 6). Converting to numbers: c=2, i=8, p=15, h=7, e=4, r=17.

Alice wants to encrypt: "thiscryptosystemisnotsecure"

Step 1 — convert plaintext to numbers:

t  h  i  s  c  r  y  p  t  o  s  y  s  t  e  m  i  s  n  o  t  s  e  c  u  r  e
19 7  8  18 2  17 24 15 19 14 18 24 18 19 4  12 8  18 13 14 19 18 4  2  20 17 4

Step 2 — divide into blocks of 6 and add the key (mod 26):

Block 1:  19  7  8 18  2 17     Key:  2  8 15  7  4 17
          ─────────────────          ─────────────────
Sum:      21 15 23 25  6  8  (mod 26)
Letters:   v  p  x  z  g  i

Block 2:  24 15 19 14 18 24     Key:  2  8 15  7  4 17
          ─────────────────          ─────────────────
Sum:       0 23  8 21 22 15  (mod 26)
Letters:   a  x  i  v  w  p

Block 3:  18 19  4 12  8 18     Key:  2  8 15  7  4 17
          ─────────────────          ─────────────────
Sum:      20  1 19 19 12  9  (mod 26)
Letters:   u  b  t  t  m  j

And so on for the remaining characters.

Clever?

We look at every instance of the letter "s" (= 18) in the plaintext:

Position 4 (in block 1): shifted by k4 = 7 → ciphertext "z"
Position 5 (in block 2, as 'position 5'): shifted by k5 = 4 → ciphertext "w"
Position 1 (in block 3): shifted by k1 = 2 → ciphertext "u"

The same plaintext letter "s" produces three different ciphertext letters: z, w, u. The one-to-one relationship between plaintext and ciphertext letters and the very thing that made frequency analysis work, is broken.

The key space is still sufficiently large. The postman prepares his frequency chart and finds… no clear pattern. The most frequent ciphertext letter doesn't cleanly correspond to "e" anymore. Victory for Alice and Bob? Our Cryptography journey ends here?

Ofc not :P.

Not Clever!

The Vigenère cipher resisted cryptanalysis for centuries and was even called "le chiffre indéchiffrable" (the indecipherable cipher). But our postman has evolved again... a pattern hunter! And the Vigenère falls to an elegant two-staged attack.

Stage 1: Find the Key Length t

Several methods exist to determine t, including Kasiski examination and the index of coincidence. The core idea behind both: if the key has period t, then the ciphertext has a subtle periodic structure that can be statistically detected.

I'll leave the details of Stage 1 as a gift for you, my friend, the Wikipedia articles are excellent. The important thing is: given enough ciphertext, the key length t can be determined.

Stage 2: Recover the Key (t Independent Frequency Analyses)

Once you know t, the rest is a familiar trick. Here's the insight:

Consider every t-th character of the ciphertext, starting from position 1:

c1, c1+t, c1+2t, c1+3t, …

All of these characters were encrypted with the same shift k1. So this subsequence is just a Caesar cipher!

Now do the same for position 2:

c2, c2+t, c2+2t, c2+3t, …

This stream was all shifted by k2. Another independent shift cipher to crack.

Repeat for positions 3, 4, …, t. We have t independent shift ciphers and we can use frequency analysis for each of them, each recovering one character of the key. Once we have all t key characters, we have the full key.

For this to work, we need the ciphertext to be long enough that each of the t streams has sufficient statistical signal. But for any fixed key length t, a sufficiently long message will always be breakable.

The Vigenère cipher, the "indecipherable cipher", broken in ciphertext-only attack. Not a great look :<

The Scoreboard

Let's step back and take stock. Three ciphers, three attacks, all in the weakest possible attack model (COA):

Cipher	Key Space	Broken By	Attack Model
Shift Cipher	26	Brute Force	COA
Mono-Alphabetic Substitution	26! ≈ 2⁸⁸	Frequency Analysis	COA
Vigenère Cipher	26^t (periodic)	Kasiski + Frequency Analysis	COA

Remember that COA is the weakest adversary. The postman has only the ciphertext. Imagine how much worse these ciphers would fare against KPA or CPA adversaries, who have plaintext-ciphertext pairs or even an encryption oracle.

Enter Cryptography

A pattern that repeated for centuries:

Someone proposes a "clever" cipher.
Everyone thinks it's secure.
Someone finds an attack.
Repeat.

The fundamental problem with classical cryptography was that it was an art, not a science:

No formal definitions of what "secure" means
No stated assumptions about what the attacker can or cannot do
No mathematical proofs that the cipher actually achieves its claimed security

Sound familiar? I walked through five attempts at defining "secure" and showed how each one failed. That's exactly the kind of imprecision that plagued classical cryptography for millennia.

The Three Principles of Modern Cryptography

Modern cryptography fixes this by resting on three pillars:

Principle 1: Formal Security Definitions

Don't just say "this cipher is secure." Define exactly what "secure" means in mathematical terms. Against what kind of adversary? With what computational resources? What exactly should the adversary be unable to compute?

We saw this begin with our series of attempts at defining privacy, and with the attack model hierarchy (COA → KPA → CPA → CCA). We'll arrive at precise, mathematical definitions that leave no room for hand-waving.

Principle 2: Precise Statement of Assumptions

Every construction in modern cryptography is built on some underlying hardness assumption, i.e, a mathematical problem believed to be computationally hard. For example:

"Factoring large integers is hard" (used in RSA)
"Computing discrete logarithms is hard" (used in Diffie-Hellman)

These assumptions (axioms) are unproven. We don't have mathematical proofs that these problems are truly hard. But by stating them explicitly, we achieve two things:

We can compare different constructions by comparing their assumptions.
If a construction is broken, we know exactly which assumption failed.

This is infinitely better than the classical approach of hoping no one finds an attack.

Principle 3: Rigorous Mathematical Proofs

Once we have a definition, Z (Principle 1) and an assumption, X (Principle 2), we mathematically prove that the construction, Y, satisfies the definition, assuming the underlying hardness assumption holds.

The structure is always:

"If X, then Y is Z-secure."

From Intuition to Formal Security

The historical ciphers all fail because ∃ an efficient adversary A that can recover m (or compute some function of m) from c, even in the weakest (COA) attack model.

This suggests a cleaner requirement. What if we demanded:

∀ m0, m1 ∈ M, ∀ c ∈ C: Pr[C = c | M = m0] = Pr[C = c | M = m1]

In other words: the ciphertext distribution should be completely independent of which message was encrypted. The adversary, no matter how powerful, stares at c and learns nothing about whether m0 or m1 was the plaintext.

What's Next?

Alice and Bob had all their ciphers broken. Wah wah wah :<

But the next blog will answer the question we've been teasing:

How do you mathematically formalize whether the ciphertext "helped" the attacker?

That leads us to probability theory, random variables, and the first formal notion of security in cryptographic history. One so strong that it's provably unbreakable, even against an adversary with unlimited computing power. It was defined by Claude Shannon in 1949. It's called perfect secrecy.

But fair warning: more math incoming. You've been warned!

Acknowledgment

So the next time someone tells you they've invented an "unbreakable" cipher, ask them three questions: What's your formal security definition? What's your hardness assumption? Where's your proof? If they can't answer all three... well, you've read this blog. You know how that story ends.

Note: The mathematical formulations in this blog are simplified for readability. The worked examples are exact.

Note: The diagrams in this blog are AI-generated and meant to be illustrative, not precise technical specifications.

Decoding Cryptography: Understanding the Attacker (and the 4 Attack Models)

Anurag Jain — Thu, 09 Jul 2026 14:24:36 +0000

The Love Letter Problem

Remember when you were a kid and wanted to write a love letter to your sweetheart, but a nosy neighbour kept peeking while you were trying to write?

This has been a problem faced by people ever since we learnt how to communicate.

We can't always stop people from peeking, but what if, even if they read the message, only the one for whom the message is intended can understand it? Enter the concept of Cryptography .

From Art to Science

Cryptography started as an art. An art of making puzzles that could only be solved by people in the know. An example would be "crypto" turned to "dtbqvr" using Vigenère cipher. But you couldn't be sure with a certain probability that no one would be able to crack the cipher (other than the people meant to, of course). So how do you actually know your puzzle is hard to crack?

As our computing powers progressed, cryptography turned from an art form to a solid mathematical field. Read on to find why that matters.

Symmetric Encryption — Alice and Bob

Now, let's get back to your problem of having a Peeping Tom over your shoulder but wanting to convey your love in writing. For a moment, let's forget this distracting analogy and consider the case of two famous friends Alice and Bob.

Alice and Bob want to correspond secretly, but they don't trust the postman to not open their letters. So they come up with a key — a tool they would use to lock their letters so that only those with the key can open the letters. For the sake of avoiding any future confusion, I want to clarify that whenever I mention key, I mean a number (could be any random number really:P).

Alice (the sender) writes the letter (message), locks the letter with the key (this process is called encryption). The locked letter (ciphertext) is sent through the post office (the channel). Bob (the receiver) obtains the letter and uses the same key to open it (a process termed decryption).

Whenever the sender and receiver share a secret key to encrypt and decrypt their messages, the process is known as "symmetric encryption". Encryption protects confidentiality, but by itself does not necessarily protect against tampering. Some examples of Symmetric Encryption schemes are AES, 3DES, ChaCha20 etc.

Kerckhoffs' Principle — Why We Need Math

Now here's the thing. Pre-modern cryptography relied on clever looking algorithms and assumed that the attacker (our peeping Tom) won't know the algorithm being used. The security came from keeping the method, i.e., the algorithm, secret. That changed in 1883.

That year, Kerckhoffs' Principle was coined. It states that "a cryptographic system should be secure even if everything about the system, except the key, is public knowledge".

In our analogy, we simply assume the postman already knows exactly how Alice and Bob are locking their letters. The only thing he doesn't know is the key. And yet, the system should still be secure.

Why is this a good idea? A few reasons:

A key is short (say, 256 bits). An algorithm is thousands of lines of code. Keeping a key secret is far easier than keeping an entire algorithm secret.
If a key leaks, you just pick a new one. If an algorithm leaks, you need to invent a new algorithm — that's much harder.
Published algorithms go through public scrutiny. An algorithm that has survived 30+ years of attacks from the world's best cryptographers is far more trustworthy than a proprietary black box.

But this also means we can no longer just wave our hands and say "trust me, it's secure". If the algorithm is public, we need mathematical proof that knowing the algorithm doesn't help the attacker. This is what turned cryptography from an art into a science.

The Key Sharing Problem

As the reader, now you wonder, how did Alice and Bob actually share the key in the first place? If they could share the key, couldn't they share the secret message the same way? These are the questions we answer next, just be patient.

Asymmetric Encryption — No Shared Key Needed

It is easy to calculate 1013 * 9973 by hand. If you have a calculator, you won't even be afraid of 10 times longer multiplications. But what if I ask you to factorize "15972623"? It is very difficult to do so by hand.

And what if instead of an 8 digit number, it was a 500 digit number with just two prime factors? Just the number of 250 digit numbers is too huge to fathom and finding the factors is believed to be computationally infeasible for sufficiently large numbers.

The best known attacks against RSA, an asymmetric encryption algorithm, involve factoring a very large integer into its prime factors. No efficient algorithm for this problem is known.

Asymmetric encryption involves sharing a message over an unsecure channel without a shared key. Instead, there are two keys: a public key (which everyone can see) and a private key (which only the receiver holds). Anyone can encrypt a message using the public key, but only the holder of the private key can decrypt it.

RSA, ECC, ElGamal are a few commonly used Asymmetric Encryption schemes.

Why Both? Symmetric + Asymmetric

If I can share messages without a shared key, why do I need the key in the first place? Turns out using a symmetric key is much faster, and as the message gets longer, the difference becomes dramatic. So in practice, we use asymmetric encryption to share a short key (e.g. 256 bits), and then use symmetric encryption with that key for the actual messages. Best of both worlds.

Note: readers beware that this blog has gone wild and will be a bit technical hereon.

You might find my use of a few terms (like negligible, difficult, short, long etc) vague. From now on, we'll start being more precise about what these things actually mean.

Deterministic vs Randomized Algorithms

Before we formalize encryption, we need to understand a distinction that is fundamental to making encryption secure.

A deterministic algorithm is what you'd normally expect: give it the same input, and it always produces the same output. Run it a hundred times with input x, and you get the same output y a hundred times. No surprises.

A randomized algorithm is different. Like flipping a coin, running the same algorithm with the same input twice might give you two different outputs. The output depends not just on the input, but also on chance.

Why does this matter for encryption? Imagine Alice encrypts "I love you" with the same key twice. If the encryption algorithm is deterministic, the postman sees the same ciphertext appear twice and exclaims: "Aha, she's sending the same message again!" He doesn't know what the message is, but he knows it's being repeated — and that alone can be valuable information.

So, encryption must use fresh randomness (or an equivalent unique nonce) so that encrypting the same message twice does not produce the same ciphertext.

The Formal Syntax: Gen, Enc, Dec

Now that you understand randomness, let's be precise about what a symmetric encryption scheme actually is. It consists of 3 algorithms:

Gen() → k (Key Generation)

The key generation algorithm takes no input. Internally, it generates random bits and outputs a key k. Since it's randomized, every time you run Gen, you could get a different key. The set of all possible keys it could output is called the key space K.

For example, if Gen outputs 256-bit keys, then the key space is the set of all 256-bit strings — that's 2²⁵⁶ possible keys.

Enc(m, k) → c (Encryption)

The encryption algorithm takes the plaintext m and a key k, uses fresh randomness (or a nonce), and outputs a ciphertext c. Since it uses randomness, encrypting the same message with the same key multiple times will produce different ciphertexts — exactly what we want.

Dec(c, k) → m (Decryption)

The decryption algorithm takes a ciphertext c and the key k, and outputs the original plaintext m. This one is deterministic — and it has to be! If Bob decrypts the same message as "I love you" once and "I hate you" the second time around, that would be a tragedy.

Notice the asymmetry: Gen and Enc are randomized, but Dec is deterministic.

Correctness

The first property we demand from any encryption scheme is straightforward: it should actually work.

Formally:

Dec(Enc(m, k), k) = m

(for every key k that Gen could output and every message m)

Think of it like a physical lock. If Alice locks a box with a key and sends it to Bob, and Bob has a copy of the same key, he should be able to open the box. If the key doesn't open the lock it created — well, that's a pretty useless lock.

That was simple right?

Privacy — What Does "Secure" Even Mean?

Intuitively, we want the ciphertext to not reveal anything about the message to someone who doesn't have the key. But formalizing this intuition, It’s Tricky. Let me walk you through a series of reasonable looking attempts.

Attempt 1: "An encryption scheme is secure if the ciphertext doesn't reveal the key."

Makes sense — if the attacker gets the key, they can decrypt everything. So at minimum, the ciphertext shouldn't leak the key.

But consider an encryption algorithm that just outputs the plaintext as the ciphertext: Enc(m, k) = m. The ciphertext reveals nothing about the key. Obviously, this fails.

Attempt 2: "An encryption scheme is secure if the ciphertext doesn't reveal the plaintext."

Alice just writes "I l$ve you" and sends the letter. How can you say that this reveals the plaintext? We need to be more precise.

Attempt 3: "An encryption scheme is secure if the ciphertext doesn't reveal any individual character of the plaintext."

This plugs the hole from attempt 2. But again, our example of Vigenère cipher in the beginning should be a hint to why this attempt is still not final.

Attempt 4: "An encryption scheme is secure if the ciphertext doesn't reveal any meaningful information about the plaintext."

Sounds good! But what does meaningful mean? Maths might have the answer.

Attempt 5: "An encryption scheme is secure if the ciphertext doesn't help the attacker compute **any function* of the plaintext."*

Now we're getting somewhere. The ciphertext should be useless for computing anything about the message, whether that's the message itself, a single character, a range, or any other property.

But two questions remain:

How do we mathematically formalize whether the ciphertext "helped" the attacker?
What exactly can the attacker do? Just stare at the ciphertext? Or something more?

The first question leads to deep probability theory (which I'll save for another blog). The second question is what we tackle next.

Attack Models — What Can the Attacker Do?

In all the models below, the setup is the same: Alice and Bob have agreed on a key k (unknown to the postman), Alice has encrypted a message, and the postman has intercepted the ciphertext c. The postman knows the encryption and decryption algorithms (thanks, Kerckhoffs). The goal of the postman is to compute some function of the underlying plaintext.

What differs across models is what additional powers the postman has.

COA — Ciphertext Only Attack

The simplest scenario. The postman has only the ciphertext. That's it. The postman reads the envelope and tries to figure out the message. No tricks, no prior knowledge — just the scrambled text.

This is a passive, eavesdropping-only attack. Every encryption scheme should at least be secure against this.

Mathematically, we write this as:

Adversary sees: c₁, c₂, ..., cₜ (intercepted ciphertexts)
Adversary knows: Enc, Dec algorithms (Kerckhoffs' Principle)
Adversary DOES NOT know: key k
Goal: Learn something about the plaintexts m₁, m₂, ...

KPA — Known Plaintext Attack

The postman now has something extra: a collection of (message, ciphertext) pairs encrypted under the same unknown key k. Think of it this way — the postman knows that every letter starts with "Dear Bob", so he already knows what the encryption of "Dear Bob" looks like under this key.

Armed with this database, a new letter arrives, and the postman tries to crack it. Notice: if encryption were deterministic and the new message happened to be one the postman already has, the ciphertext would match and the game would be over. Here lies another reason encryption must be randomized.

Mathematically:

Adversary has: database of (mᵢ, cᵢ) pairs under key k
These came from: previous messages that lost confidentiality
Goal: Decrypt a NEW ciphertext c (not in the database)

CPA — Chosen Plaintext Attack

Now things get serious. The postman can now choose messages and get their encryptions under the unknown key k. It's as if the postman can trick Alice into encrypting messages of the postman's choice — without Alice realizing it.

"Wait, how is that possible in real life?" you ask. I'll show some concrete examples in later blogs. For now, Go with the Flow.

The postman builds up a dictionary of (chosen message, ciphertext) pairs, and then tries to learn something about a fresh encrypted message. The postman is now actively interacting with the system, not just listening.

Mathematically:

Adversary can: CHOOSE plaintexts m₁, m₂, ... and get Enc_k(mᵢ)
Modeled as: adversary has an "encryption oracle" — a black box that encrypts anything it asks, under the unknown key k
Goal: Decrypt a NEW challenge ciphertext c (that they did not previously ask the oracle to encrypt)

CCA — Chosen Ciphertext Attack

The nuclear option. The postman can:

Get encryptions of any chosen messages (like CPA), AND
Get decryptions of any chosen ciphertexts (except the challenge ciphertext itself) — by tricking Bob into decrypting ciphertexts of the postman's choice.

The postman can mix and match these services in any order, building up databases of both (message → ciphertext) and (ciphertext → message) pairs under the unknown key.

Then a fresh ciphertext arrives, and the postman tries to learn something about a fresh encrypted message using everything they've accumulated.

When we say "an encryption scheme is CCA-secure", we mean that even with all this power, the postman still can't compute any function of the fresh plaintext. That's a very strong guarantee.

Formally:

Adversary can: Get encryption oracle (like CPA) PLUS get decryption oracle — submit ciphertexts of its choice (except the challenge ciphertext itself) and receive the plaintexts
Goal: Decrypt a FRESH new challenge ciphertext c

Quick Reference

Attack Model	What the Postman Has
COA (Ciphertext-Only)	Only the intercepted ciphertext.
KPA (Known-Plaintext)	A database of historical plaintexts and their matching ciphertexts.
CPA (Chosen-Plaintext)	An "encryption oracle" to get the ciphertext for any message they choose.
CCA (Chosen-Ciphertext)	Both an encryption oracle and a decryption oracle to test any ciphertext.

The security hierarchy:

CCA security implies CPA security, which implies KPA security, which implies COA security.

Each successive model gives the adversary strictly more capabilities than the previous one. An encryption scheme that is secure under CCA is secure under all the weaker models too.

Beyond Secure Communication

Cryptography goes far beyond Alice and Bob sending secret letters. Here's a taste of what else it enables:

Cryptocurrency (e.g. Bitcoin) — digital cash that prevents double-spending and preserves anonymity, without any central bank.
Zero-Knowledge Proofs — proving you know something (like the factors of a large number) without revealing what you know.
Secret Sharing — splitting a secret across multiple parties so that no single party can reconstruct it alone.
Secure Multi-Party Computation — multiple parties jointly compute a function over their private inputs, without revealing those inputs to each other.
Homomorphic Encryption — performing computations on encrypted data without ever decrypting it.

Each of these deserves its own blog post. For now, just know that the foundations we've discussed — symmetric encryption, asymmetric encryption, formal security definitions, and attack models — are the building blocks for all of these.

Acknowledgment

A lot of the technical rigor and structure in this blog is inspired by my reading of "Introduction to Modern Cryptography (Second Edition)" by Jonathan Katz and Yehuda Lindell. It's a fantastic textbook if you want to dive deeper into the math!

So the next time you want to write that love letter, remember: cryptography has your back. Just make sure you pick the right key, keep it to yourself, and for the love of security — don't use a proprietary cipher.

Edit: Link to next blog

Note: The diagrams in this blog are AI-generated and meant to be illustrative, not precise technical specifications.

DEV Community: Anurag Jain

Decoding Cryptography: From Perfect Secrecy to Computational Security

(Lion Roaring)…

Computation Theory Primer

The Security Parameter

Efficient Algorithms

Negligible Functions

Why These Two Concepts Work Together

Perfect Secrecy

What Can Be Perfect?

Shannon's Definition

An Equivalent View

The One-Time Pad

The Perfect Mask

The Construction

Correctness

The Proof

Don't Strive for Perfection

Limitation 1: The Key Must Be as Long as the Message

Limitation 2: The Key Cannot Be Reused

Need to chillax

The Birth of Computational Security

Why These Concessions Are Necessary

Choosing n: Where You Draw the Line

What's Next?

Acknowledgment

Decoding Cryptography: The Fall of Historical Ciphers

Previously, on "The Love Letter Problem"…

Modular Arithmetic 101

Letters as Numbers

Cipher #1: The Shift Cipher (Caesar Cipher)

Simple Example

Breaking the Caesar Cipher: Brute Force

The Sufficient Key Space Principle

Cipher #2: The Mono-Alphabetic Substitution Cipher

The Key Space: 26!

Breaking the Substitution Cipher: Frequency Analysis

The Fingerprint of Language

The Attack

Cipher #3: The Vigenère Cipher

Example

Clever?

Not Clever!

Stage 1: Find the Key Length t

Stage 2: Recover the Key (t Independent Frequency Analyses)

The Vigenère cipher, the "indecipherable cipher", broken in ciphertext-only attack. Not a great look :<

The Scoreboard

Enter Cryptography

The Three Principles of Modern Cryptography

Principle 1: Formal Security Definitions

Principle 2: Precise Statement of Assumptions

Principle 3: Rigorous Mathematical Proofs

From Intuition to Formal Security

What's Next?

Acknowledgment

Decoding Cryptography: Understanding the Attacker (and the 4 Attack Models)

The Love Letter Problem

From Art to Science

Symmetric Encryption — Alice and Bob

Kerckhoffs' Principle — Why We Need Math

The Key Sharing Problem

Asymmetric Encryption — No Shared Key Needed

Why Both? Symmetric + Asymmetric

Deterministic vs Randomized Algorithms

The Formal Syntax: Gen, Enc, Dec

Correctness

Privacy — What Does "Secure" Even Mean?

Attack Models — What Can the Attacker Do?

COA — Ciphertext Only Attack

KPA — Known Plaintext Attack

CPA — Chosen Plaintext Attack

CCA — Chosen Ciphertext Attack

Quick Reference

Beyond Secure Communication

Acknowledgment