Cryptography basics and Kerckhoffs's principle

Plaintext, ciphertext, key and the symmetric cipher model, what cryptography does and does not achieve, and Kerckhoffs's principle illustrated by two historical violations, GSM A5/1 and DVD CSS.

Define plaintext, ciphertext and key using the unit's own notation.
Distinguish symmetric from asymmetric cryptography by the relationship between the encryption and decryption keys.
State Kerckhoffs's principle precisely, including what has to stay secret and what does not.
Explain why GSM A5/1 and the DVD Content Scrambling System are historical violations of the principle.

12 min read

Intuition

Two people want to exchange a message that a third party might intercept along the way. The obvious fix is to disguise the message so that only the intended reader can undo the disguise. Cryptography is the science built around doing that reliably: turning a readable message into something unreadable, and back again, using a secret that only the right people hold.

Mechanism

In the unit’s own notation, plaintext $p$ is the unprotected data, built from symbols in an alphabet $R = \{r_1, r_2, \ldots, r_n\}$ : for ordinary English this is $\{$ A-Z, a-z, 0-9 $\}$ . Encryption applies a cipher function $\text{Enc}$ and a key $k_e$ to turn $p$ into ciphertext $c$ . Ciphertext is drawn from its own alphabet $S = \{s_1, s_2, \ldots, s_m\}$ , which need not match $R$ in symbols or in size. Decryption reverses this with a decipher function $\text{Dec}$ and a key $k_d$ .

Formula

Encryption and decryption

\text{Enc}_{k_e}(p) = c, \qquad \text{Dec}_{k_d}(c) = p

$p$: plaintext, drawn from an alphabet R
$c$: ciphertext, drawn from an alphabet S that need not match R
$k_e$: the encryption key
$k_d$: the decryption key

In symmetric cryptography k_e = k_d, or k_d is trivially derivable from k_e.

Mechanism

Whether $k_e$ and $k_d$ are the same key splits cryptography into two families. Symmetric cryptography sets $k_e = k_d$ , or makes $k_d$ trivially derivable from $k_e$ . Also called shared-key cryptography, built on algorithms that shuffle and remap symbols. Asymmetric cryptography makes $k_e \neq k_d$ , and makes it infeasible to compute $k_d$ from $k_e$ . Also called public-key cryptography, built on the hardness of a mathematical problem rather than on symbol-shuffling. This module covers only the symmetric side; asymmetric cryptography is Module 6.

In symmetric cryptography the encryption key equals the decryption key (or one is trivially derived from the other), so Alice and Bob must already share k before any ciphertext moves — the key exchange problem every symmetric scheme pushes elsewhere. Eve, the eavesdropper, sees only the ciphertext on the main channel; the security of the whole scheme rests on that being enough.

Exam detail

The diagram above makes one assumption explicit: Alice and Bob already share $k$ before any ciphertext crosses the channel Eve is watching. Cryptography secures data given that a shared secret exists. It does not, by itself, solve how that secret got shared in the first place. That problem, key distribution, is pushed elsewhere, and it is exactly what makes the one-time pad impractical later in this module.

Within this unit, cryptography is used for three things: confidentiality, through symmetric and asymmetric encryption; integrity, through Message Authentication Codes (MACs), signatures and hash functions; and authentication, through protocols built on top of those. Non-repudiation, privacy and anonymity are all real applications of cryptography too, but the unit states plainly that they sit outside what this course covers.

Mechanism

Kerckhoffs’s principle, stated precisely: a cryptographic mechanism’s security must depend only on the secrecy of the keys used, never on the mechanism itself, or anything else, being secret. Nearly every mainstream algorithm in real use, AES and RSA included, is fully public. Anyone can read exactly how they work. Their security rests entirely on the secrecy of the key.

This is deliberate. A published design gets scrutinised by the whole cryptographic community rather than just its authors (the “many eyes” argument). It is why NIST runs open competitions to select new standards: submissions are public from the start, and the global community searches them for flaws before one is chosen. AES itself was selected this way.

Threat

Designing a system whose security depends on the algorithm’s own secrecy, not the key’s, is the mistake Kerckhoffs’s principle warns against. Once that design leaks or is reverse-engineered, every deployment of it fails at once. Two historical cases: GSM A5/1, a proprietary stream cipher with a 64-bit key used to encrypt 2G mobile traffic. Weaknesses surfaced in 1994, and by the late 1990s an eavesdropper who gathered enough consecutive encrypted frames could recover the secret key with moderate computational power, a ciphertext-only attack. And the DVD Content Scrambling System (CSS): a copy-protection scheme relying entirely on its algorithm staying secret. Once CSS was reverse-engineered and published, the entire system it protected was compromised, all at once, for every disc it had ever covered.

Control

Kerckhoffs’s principle is the fix: build the system so its security depends only on the key, and publish the mechanism itself for open review. Neither A5/1 nor CSS did this. Both bet their security on secrecy that could not, and did not, hold.

Pitfall

Kerckhoffs’s principle does not mean nothing needs to stay secret. The key still does. What the principle rules out is designing a system that needs its algorithm hidden to be safe: a public algorithm and a secret key is the goal, not “publish everything.”

Recall

Why does publishing a cryptographic algorithm not weaken it, if the design is sound?

Because a sound design’s security comes entirely from the secrecy of the key, not the mechanism. Publishing the algorithm invites the wider cryptographic community to search it for flaws before it is trusted. That is exactly what NIST’s open AES competition did, and exactly what GSM A5/1 and CSS skipped, to their cost.

Aside

The GSM A5/1 case is doubly instructive: the design looked secure to the people who built and shipped it, and an attacker who had never seen the specification could still take it apart once it leaked. A system that merely seems secure to its own developers is not the same thing as a system that is secure.

Source

Week 4 notes PDF