Kerckhoffs's Principle

Read it carefully, because it is stronger than it first appears. It does not say the algorithm may become public and you should survive that embarrassment. It says you should design from day one as if the algorithm were already published: the mathematics, the source code, the protocol, the block diagrams, all of it sitting on the adversary's desk. If the system is still secure in that scenario, the entire weight of your security rests on one small, manageable thing: the key.

The inverse approach (hoping the enemy never figures out how the system works) has a name too: security through obscurity. Obscurity can add a speed bump on top of real security, but the moment it is the foundation, you have built on sand, because a secret shared by every device, every developer, and every factory that ships your product is not a secret. It is a countdown.

Auguste Kerckhoffs, a Dutch-born linguist and cryptographer teaching in Paris, published a two-part essay called La Cryptographie militaire in the Journal des sciences militaires in 1883. Military telegraphy was booming, and armies needed ciphers that survived real field conditions: captured codebooks, defecting clerks, stolen equipment. Kerckhoffs laid out six design requirements. The second one made him immortal.

Notice how modern the reasoning is. Rules 2 and 3 together form a complete security philosophy: assume the machinery is captured, and make the key the one thing you can change cheaply. An army cannot redesign its cipher machines mid-war, but it can issue new keys every morning. Substitute "firmware in a billion devices" for "cipher machines" and the argument has not aged a day.

Shannon's blunt restatement

Sixty-six years later, Claude Shannon (founding information theory and modern cryptanalysis more or less in the process) compressed Kerckhoffs's second rule into the form most working cryptographers quote:

The enemy knows the system. Claude Shannon · "Communication Theory of Secrecy Systems," 1949

Sometimes called Shannon's maxim, it is the same principle with the politeness removed. Design for the worst case, because at scale the worst case is simply the case.

If you want to see Kerckhoffs's Principle operating in the real world, you do not need a hypothetical. You need only look at the cipher protecting this very page in transit: AES.

In 1997, when the U.S. government needed a replacement for the aging DES, it did something that would have seemed insane under a security-through-obscurity worldview: it asked the entire planet to submit ciphers, published every submission in full, and invited the world's cryptographers to spend three years tearing them apart in public. The winner, Rijndael, designed by Belgian cryptographers Joan Daemen and Vincent Rijmen, became AES in 2001. Its complete specification (every constant, every table, every step) is a free download. There has never been a secret to leak.

And that is precisely why it is trusted with everything from your bank session to classified government traffic:

• Public design means real evidence. Twenty-plus years of open, adversarial cryptanalysis by the best minds in the field have produced no practical break. A secret algorithm can never offer that kind of testimony; it can only offer its owner's word.
• The only secret is the key. An AES key is 16 to 32 bytes: trivial to generate, cheap to protect, and, most importantly, replaceable. Compromise a key and you rotate it. The system survives.
• Anyone can implement it. Because nothing is hidden, AES could be built into every CPU, every TLS library, every phone, with full interoperability and public review of the implementations themselves.

Your TLS connections, your device's disk encryption, and your Wi-Fi all lean on this publicly documented algorithm every day. The full tour of where AES lives, and how it has held up, is on the AES page; the round-by-round machinery is in Block Ciphers and AES.

The contrast case that makes the principle vivid comes from the phone in your pocket's ancestors. When the GSM cellular standard was designed in the late 1980s, its voice-encryption ciphers, A5/1 (the strong version) and A5/2 (a deliberately weakened export version), were kept confidential. Security rested partly on the hope that nobody outside the consortium would ever learn how they worked.

Everybody learned how they worked.

• Through the 1990s the designs leaked and were reverse engineered from documentation and handset silicon, with full descriptions published by 1999.
• A5/2 collapsed almost immediately. Cryptographers broke it within a month of its public reconstruction, and later work recovered its keys in real time on ordinary hardware. It was so weak it became a liability: attacks could downgrade a phone to A5/2, recover the session key, and use that key against A5/1 traffic. The industry eventually had to prohibit A5/2 outright.
• A5/1 fell more slowly but surely. Once the algorithm was public, academic attacks accumulated until, by 2009–2010, precomputed rainbow tables made eavesdropping on A5/1 calls feasible with commodity radios and consumer hardware.

Here is the Kerckhoffs lesson in one line: the secrecy was load-bearing, and it was welded to the hardware. When the algorithms leaked, there was no key to rotate; the broken cipher was burned into hundreds of millions of handsets and base stations across the globe. Fixing the mistake meant decades of infrastructure turnover, not a Tuesday patch.

The graveyard has more headstones

GSM is not an isolated incident; it is the pattern. The DVD industry's secret CSS scrambling system was reverse engineered in 1999 (the famous DeCSS episode) and its 40-bit design fell instantly. NXP's MIFARE Crypto-1, the secret cipher inside hundreds of millions of transit and building-access cards, was reverse engineered from the chip itself in 2007–2008 and broken within months; entire fare systems had to be replaced. Every one of these systems shared the same architecture: the algorithm was the secret, the secret leaked, and there was nothing left to rotate.

It is worth being precise about why the pattern repeats, because "obscurity is bad" is a slogan, and slogans do not survive contact with a persuasive vendor. The mechanics:

• An algorithm cannot stay secret at scale. It exists in every device that uses it, every binary that implements it, every engineer's head who built it. Silicon can be decapped, firmware can be disassembled, employees change jobs. A secret with a million copies is a publication with extra steps.
• An algorithm cannot be rotated. Keys are designed to be changed; that is Kerckhoffs's rule 3. Algorithms are designed to be deployed. When the algorithm is the secret, its exposure is unrecoverable short of replacing the fleet.
• Secrecy prevents the only test that matters. The confidence we have in AES is not faith; it is the residue of thousands of failed attacks by experts with every incentive to succeed. A cipher nobody outside the company has examined has, from the defender's perspective, been examined by nobody. Absence of published breaks is not evidence of strength when publication was never possible.
• Obscurity concentrates failure. With a public algorithm, each deployment's security fails independently, one leaked key at a time. With a secret algorithm, every deployment on Earth shares one catastrophic single point of failure.

None of this means you must volunteer your network diagrams to strangers. Not advertising internal details is ordinary hygiene, and defense in depth welcomes every extra layer, obscurity included. The principle draws a sharper line: obscurity may garnish your security. It must never be your security.

Kerckhoffs's Principle is not trivia; it is a working checklist you will apply for the rest of your career, well beyond ciphers:

Before leaving this page, confirm you can answer the following without looking:

1. State Kerckhoffs's Principle in one sentence, and Shannon's maxim in five words.
2. Why must the key, rather than the algorithm, carry the secrecy in a well-designed system?
3. How does AES's history demonstrate the principle paying off in practice?
4. What happened to GSM's A5 ciphers, and why was recovery so expensive?
5. Where is the legitimate (and illegitimate) place for obscurity in a security design?

If all five are solid, you now hold the single idea that separates trustworthy cryptography from theater. Carry it into AES if you arrived here first, or onward through the rest of the symmetric track.