“When the Enemy Gets the Manual”
Suppose the enemy gets the manual.
Not just the ciphertext. Not just a suspicious strip of leather, a repeated keyword, an intercepted letter or an odd semaphore signal. The manual. The diagram. The source code. The protocol description. The device. The training notes.
Images in this article are generated by
EU AI Act Regulation 2024/1689
Plus the app binary. The helpful vendor PDF with four diagrams, six trademarks and one sentence doing all the security work.
Does the system still stand?
That is Kerckhoffs’ question.
It is also the question that closes the first octet of this series, because the first seven artefacts have been quietly building towards it. The scytale taught us that a message can be visible but not readable. The Caesar cipher taught us that a tiny secret does not survive suspicion. Al-Kindī taught us that language leaks statistics. Vigenère taught us that repetition betrays structure. Catherine of Aragon’s cipher showed secrecy as agency and workflow. Mary, Queen of Scots’ Babington cipher showed confidentiality collapsing into hostile channel control and forged message handling. The Blanc brothers showed that a network can be abused through what its records politely ignore.
Kerckhoffs gives us the rule those stories were begging for:
Do not rely on the trick staying secret.
Auguste Kerckhoffs published La cryptographie militaire in 1883, in the Journal des sciences militaires. He was writing about military cryptography in a world of telegraphs, field operations, captured equipment, written keys, clerks, couriers and enemies with both patience and pockets. In other words, he was writing for reality, something often lacking in this field.[1]
Journal des sciences militaires, 1883, Volume IX
Scan of the original, in French, naturellement, can be found here.
In case anyone isn’t completely connaît avec colloquial military French from the 1880s, I have translated the essay into English, retaining period terminology, because it is worth a read for the insight it provides into Kerckhoffs’ advanced thinking for this time.
Part 1, in English translation
Part 2, in English translation
He set out six conditions for a practical military cipher. The famous one is the second: the system should not require secrecy and should be able to fall into enemy hands without inconvenience. In modern form, this becomes:
A cryptosystem should remain secure even if everything about it is public
except the key.[1]
That sentence is one of the load-bearing beams of modern cryptography. Savour it, absorb it, feel it. It is absolutely foundational and critical.
It is also often misunderstood. Kerckhoffs was not saying that secrets do not matter. Cryptography is full of secrets. Keys are secret. Passwords are secret. Seeds, session keys, private keys, recovery codes and token-signing keys are secret. If these leak, bad things happen.
The point is narrower and stronger: the long-term secrecy of the design should
not be necessary for security.
The design should be expected to become known. The algorithm should be allowed to be inspected. The protocol should be allowed to be described. The device should be expected to fall into hostile hands. The attacker should be expected to understand how the system works. If these cause the system to fail, it was not secure. It was merely unpublished.
This is the difference between a secret and a liability.
A key is meant to be secret, and all but the very worst systems are built so that keys can be changed.[10] A design is hard to change once it is built into products, standards, infrastructure, cards, radios, phones, databases, firmware and human procedures. Replacing it is like changing a tyre on a moving vehicle; not
impossible but hazardous and far better avoided in the first place.
Kerckhoffs was alive to this operational problem. His other requirements are worth remembering. He wanted systems that were practically indecipherable, yes, but also systems whose keys could be communicated and changed without written notes, systems usable over telegraph, portable systems, systems operable by one person, and systems easy enough not to require mental strain or a long list of rules.[1]
That is not ivory-tower cryptography. That is field engineering. That is someone looking at tired humans under pressure and thinking, correctly, “they will ruin this if I make it too clever.”
A significant amount of security design consists of rediscovering that sentence at great expense.
The modern slogan is sometimes given as Shannon’s maxim: the enemy knows the system. Claude Shannon’s later work made secrecy mathematical, treating cryptosystems abstractly as transformations selected by keys and analysed through probabilities, redundancy and what an enemy can infer from intercepted cryptograms.[2] Kerckhoffs gave us the operational instinct; Shannon helped give cryptography the mathematical floor. Between them sits one of the most important habits in security: assume the attacker learns more than you wish.
This assumption hurts people’s feelings, especially people selling “proprietary military-grade encryption”, a phrase that should cause nearby assurance assessors to shudder.
But the assumption is merciful. It saves us from pretending that secrets can be kept at the wrong scale.
A design leaks through documentation. It leaks through source code. It leaks through binaries. It leaks through firmware extraction, debugging, side channels, patent filings, disgruntled staff, procurement documents, training slides, reverse engineering, protocol traces, interoperability testing and the ancient human weakness for leaving important things in inappropriate places.
If your security depends on none of that ever happening, then your security is not a property. It is a hostage situation.
Kerckhoffs’ principle replaces one impossible problem with a difficult but manageable one. Instead of “keep the whole mechanism secret from everyone forever”, it says: use a public or at least inspectable mechanism, and keep a smaller, changeable key secret. If the key is compromised, rotate it. If a user leaves, revoke it. If a session ends, discard it. If an algorithm is broken, that is much worse, but at least a public algorithm has had the chance to be attacked before it is deployed across half the planet.
That chance matters.
Modern cryptography depends on public scrutiny. AES did not become trusted because someone at NIST whispered “probably fine”. NIST ran an open process to develop the Advanced Encryption Standard, and Rijndael was selected after public evaluation. The requirements for the candidate algorithms to meet were public; they included consideration for low-power devices. The resulting standard specifies AES-128, AES-192 and AES-256 using publicly described transformations
and key sizes.[3]
The same pattern continues with post-quantum cryptography. NIST’s postquantum process has involved a multi-year international competition across industry, academia and government, with some standards released and further algorithms still being developed as backups or alternatives.[4] This is Kerckhoffs’ culture in action: publish candidates, invite attack, survive scrutiny, standardise what remains standing. Civilisation occasionally learns. Do not get excited; it is still rare.
Open design also enables interoperability. If two systems need to communicate securely, they need a shared protocol, shared assumptions, test vectors and independent implementations. Secret proprietary mechanisms make this harder, and not in the useful “attacker has to work” sense. More often, they make it harder for defenders, auditors, users and researchers to work out whether the thing is doing what it claims.
There is a reason “roll your own crypto” is spoken in security circles with the same tone normal people reserve for “unlicensed dentistry”.
This does not mean openness guarantees safety. It does not. A public design can be dreadful. A well-known algorithm can be used in a terrible mode. A strong cipher can be undermined by weak randomness, reused nonces, missing authentication, bad padding, side channels, poor key storage, sloppy certificate validation, broken recovery processes or users inadvertently trained by misery to click whatever makes the box go away.
Kerckhoffs’ principle is not a spell. It is a warning label.
A system may follow the principle and still fail. But a system that violates it has already told you where to look for the rot.
The failures are not hard to find.
MIFARE Classic, used widely in contactless smartcards, relied on a proprietary stream cipher called CRYPTO1. Its design was kept secret. Researchers reverse engineered the chip and found serious vulnerabilities; later work showed practical attacks capable of retrieving secret keys.[5] This is the classic shape of the problem: secrecy delayed examination by the people most likely to help, but did not prevent examination by people determined enough to take the system apart.
GSM’s A5/1 cipher tells a related story. It began as a proprietary ciphering algorithm, was reverse engineered in the late 1990s, and later academic work demonstrated practical attacks against GSM encrypted communication and related protocol weaknesses.[6] The lesson is not that openness magically prevents all weakness. The lesson is that secrecy did not save the design; it mostly postponed public understanding until the system was already deployed at enormous scale.
A5/1 remains relevant while 2G/GSM remains in service, and UK 2G is not expected to disappear fully until around 2033. Where A5/1 is still used, 2G GSM should be treated as interceptable by capable actors.
That is the expensive version of “surprise”.
There are smaller, uglier versions everywhere. Consumer devices that rely on secret pairing rituals. “Encrypted” licence files that turn out to be reversible encoding with a checksum. APIs whose security depends on undocumented parameters. Mobile apps with hidden client-side keys. DRM schemes that assume nobody will reverse engineer the player. Web applications where access control is “the button is not shown”. Vendor protocols whose documentation is confidential, because “Kerckhoffs? Never heard of him!”
It gets worse in recent developments. Some AI systems are tempted to treat hidden prompts, hidden policies or hidden tool instructions as if they were a security boundary. But prompt injection exists precisely because natural-language instructions and untrusted data are often processed together; OWASP describes prompt injection as attacker-controlled input that manipulates model behaviour, including direct and indirect forms.[7] A hidden instruction can be useful guidance. It is not a cryptographic key. If the system grants real authority, then the defence cannot be “but the model was told not to”.
That is not Kerckhoffs. That is wishful thinking with JSON.
The wider software world has an equivalent principle in Saltzer and Schroeder’s “open design”: protection mechanisms should not depend on attackers being ignorant, but on possession of more easily protected keys or passwords. They also note that mechanisms can be examined by many reviewers without compromising safeguards, and that maintaining secrecy for widely distributed systems is simply not realistic.[8]
That last phrase should be carved above every procurement portal.
There is a nuance here, because security people like nuance.
Kerckhoffs’ principle does not mean publish your private keys. It does not mean publish the exact detection rule that would let an attacker evade your SOC tomorrow morning. It does not mean disclose a live vulnerability before a patch exists, dump all your architecture diagrams onto the pavement, or explain to criminals which compensating controls are currently held together with gaffer tape and a change freeze.
Operational secrecy still has value. Deception can have value. Embargoes can have value. Defence in depth can include things the attacker does not yet know.
But those things should not be the foundation.
There is a difference between “this detail being secret gives us extra time” and “if this detail becomes known, the entire system collapses”. The first is defence in depth. The second is Wile E. Coyote running in mid-air past the edge of a long drop waiting for Cartoon Physics to notice.
A good Kerckhoffs-shaped question is: what happens when this secret leaks?
If the answer is “we rotate a key”, that may be painful but survivable. If the answer is “we replace every deployed device, rewrite the protocol, pray nobody kept logs, and ask legal whether customers count as affected”, then the secret was too big.
This is why the principle is not just about algorithms. It is about maintainability. It is about audit. It is about incident response. It is about procurement. It is about whether an assessor is allowed to understand what they are assessing, or whether they are being asked to admire a black box while the vendor makes soothing noises.
Security claims that cannot be inspected are not impossible to trust. They are merely asking for trust in the wrong place.
The attribution story is quieter here, but still worth consideration. Kerckhoffs himself deserves to be named. English-speaking technical culture often remembers the later phrase “the enemy knows the system” more readily than the nineteenth-century author whose practical military requirements made the point. He was not just a floating surname attached to a slide. Modern biographical work by Jean-Claude Caraco, Rémi Géraud-Stewart and David Naccache explicitly aims to recover a fuller account of Kerckhoffs’ life, which is a useful reminder that even famous principles can have under-remembered people behind them.[9]
There is also labour behind the principle’s survival. Fabien Petitcolas’s work in preserving and presenting La cryptographie militaire matters. Translators matter. Archivists matter. Standards editors matter. The anonymous reviewers who find subtle flaws matter. Implementers who write test vectors matter. Maintainers of cryptographic libraries matter. Researchers who reverse engineer bad proprietary systems before criminals quietly monetise them matter. Most of them will not become the title of a principle.
Do not let “Kerckhoffs” become an abstract law detached from the very human ecosystem of preservation, review, implementation and attack that makes the law useful.
The first octet began with a stick.
It ends with an assumption.
The attacker gets the method. The attacker gets the device. The attacker gets the manual. The attacker gets time, curiosity, instruments, leaks, insiders, copies, binaries and excellent pattern recognition.
If your system survives that, perhaps it has earned a little confidence.
If it does not, then the secret was never the key.
It was the weakness waiting to be renamed.
00001000 BS
References
[1] Auguste Kerckhoffs, La cryptographie militaire, 1883, preserved by Fabien Petitcolas, for the original six requirements and the famous second condition that the system should not require secrecy or be compromised by falling into enemy hands. (Petitcolas)
[2] Claude Shannon, Communication Theory of Secrecy Systems, 1949, for the mathematical framing of secrecy systems, keys, transformations, redundancy and enemy inference from cryptograms.
[3] NIST, Advanced Encryption Standard, FIPS 197, for Rijndael’s selection through the AES competition and the public specification of AES-128, AES-192 and AES-256. (NIST Computer Security Resource Center)
[4] NIST Post-Quantum Cryptography project, for the multi-year international process leading to post-quantum cryptography standards and ongoing backup/alternative algorithms. (NIST Computer Security Resource Center)
[5] Flavio D. Garcia and colleagues, Dismantling MIFARE Classic, for the proprietary CRYPTO1 cipher, reverse engineering of the chip, and practical vulnerabilities in a widely deployed contactless smartcard system. (Flavio Garcia)
[6] Elad Barkan, Eli Biham and Nathan Keller, Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication, for practical attacks on GSM encrypted communication and related protocol weaknesses. (Springer)
[7] OWASP LLM Prompt Injection Prevention Cheat Sheet, for the modern warning that prompt injection manipulates LLM behaviour by mixing attacker-controlled instructions with data, making hidden prompts a poor security boundary. (OWASP Cheat Sheet Series)
[8] Saltzer and Schroeder, The Protection of Information in Computer Systems, especially the open design principle: protection mechanisms should not depend on attacker ignorance, but on more easily protected keys or passwords. (Massachusetts Institute of Technology)
[9] Jean-Claude Caraco, Rémi Géraud-Stewart and David Naccache, Kerckhoffs’ Legacy, for modern biographical recovery work on Kerckhoffs himself. (eprint.iacr.org)
[10] Seriously, yes. This one is so old (2010) that most of the news site URLs no longer work, but there is the European Union Vulnerability Database (EUVD) record, the CVE entry (cve.org), and most usefully of all the published research paper which is shocking reading. (syss.de)
