Kerckhoffs’s principle states that a cryptographic system should remain secure even if everything about the system, except the key, is public knowledge. Put differently, the security of a cipher must depend entirely on the secrecy of the key, not on keeping the algorithm or design hidden from attackers. The idea dates back to 1883, when Dutch-born cryptographer Auguste Kerckhoffs published it as one of six design requirements for military ciphers, and it has since become one of the most influential concepts in information security. Despite sounding counterintuitive at first, the reasoning behind it has only grown stronger with time.
What Kerckhoffs Actually Wrote
In 1883, Auguste Kerckhoffs published a two-part article in the French journal Journal des sciences militaires titled “La cryptographie militaire.” In it, he laid out six properties that a practical military cipher should have. The second of these is the one now known as Kerckhoffs’s principle: the system must not require secrecy, and it should be able to fall into enemy hands without causing problems. Kerckhoffs was writing about physical cipher devices and codebooks used by armies, and his concern was practical. A cipher machine could be captured on the battlefield. A codebook could be stolen by a spy. If the entire security of your communications depended on your enemy never seeing the machine, you were building on sand.
His reasoning was not abstract. Military cipher systems were used by thousands of soldiers across wide fronts. Keeping the design of such a system secret from every single person who handled it, maintained it, or might lose it was unrealistic. The only thing you could realistically protect across a large organization was a short, changeable key. Kerckhoffs was arguing for a kind of engineering discipline: build your system so that when the inevitable leak happens, the damage is contained.
Shannon’s Maxim and the Modern Restatement
The principle was given its modern mathematical framing by Claude Shannon, the founder of information theory. In 1949, Shannon published “Communication Theory of Secrecy Systems,” the paper that essentially created modern cryptography as a formal discipline. In it, he gave cryptographic concepts their first rigorous mathematical treatment, including proofs of security grounded in probability theory. Shannon’s version of Kerckhoffs’s principle is sometimes called Shannon’s maxim: “the enemy knows the system.”1Journal of Cybersecurity. The adversary: the philosophy of cryptography
Shannon’s formulation shifted the principle from a practical military guideline to a foundational assumption of cryptographic analysis. When you design or evaluate a cipher, you must assume the attacker knows every detail of how it works. The only unknown to the attacker is the specific key you chose. If the system is still secure under that assumption, it is genuinely strong. If it is not, then you have been relying on the attacker’s ignorance rather than on actual mathematical hardness, and ignorance is a brittle shield.
Why Keeping the Algorithm Secret Is a Bad Bet
The appeal of a secret algorithm is obvious: if the attacker does not know how your system works, they cannot attack it. The problem is that this reasoning fails under real-world conditions for several overlapping reasons.
First, secrets about algorithms are extremely hard to keep. Any system used at scale has many people involved in its design, implementation, deployment, and maintenance. Every person who knows how the system works is a potential leak. Software can be reverse-engineered. Hardware can be disassembled. The history of proprietary cryptographic systems is littered with cases where the algorithm was eventually exposed, and the system turned out to be embarrassingly weak once experts could actually examine it. The GSM mobile phone encryption standard, various pay-TV scrambling systems, and numerous proprietary RFID authentication schemes all followed this trajectory: the algorithm was kept secret, the secret leaked, and the underlying weakness was laid bare.
Second, a secret algorithm cannot benefit from public scrutiny. When a cipher design is published openly, the entire global community of cryptanalysts can try to break it. Years of failed attacks by skilled adversaries are the best evidence you can get that a cipher is strong. This is exactly how the Advanced Encryption Standard (AES) was selected: the U.S. government ran an open, multi-year competition in which proposed ciphers were published and attacked by researchers worldwide. The algorithm that survived was chosen precisely because it withstood sustained, expert assault. A secret algorithm, by contrast, has been reviewed only by its creators and perhaps a small internal team. That is a much weaker form of assurance.
Third, keys are easy to change; algorithms are not. If a key is compromised, you generate a new one. If a secret algorithm is compromised, you need to redesign and redeploy the entire system. This asymmetry makes key-based security far more resilient and operationally manageable than algorithm-based secrecy.
Security by Obscurity and Why It Has a Bad Reputation
“Security by obscurity” is the pejorative label given to any approach that relies on the attacker’s lack of knowledge about a system’s design rather than on the system’s intrinsic strength. In cryptography and software security, calling something “security by obscurity” is roughly equivalent to calling it wishful thinking. The phrase is used so reflexively that it has taken on the character of a slogan, sometimes applied without much nuance.
The core objection is sound: if your system’s only defense is that no one knows how it works, then a single leak, a single reverse-engineering effort, or a single insider threat collapses your entire security posture. This is not a theoretical concern. Proprietary encryption schemes in consumer electronics, vehicle immobilizers, and access control systems have repeatedly been broken once researchers got access to the implementation. The companies behind these systems often responded by trying to suppress the research through legal threats, which, apart from being ethically questionable, only delayed the inevitable by months.
The lesson the security community has drawn from these episodes is consistent: do not design systems whose security depends on the attacker not knowing the design. Use well-studied, publicly vetted algorithms and protocols. Make the key the only secret.
When Obscurity Actually Helps
The reflexive dismissal of anything that smells like obscurity has its own blind spots. There is a meaningful difference between relying on obscurity as your primary defense and using obscurity as an additional layer on top of a fundamentally sound system. The principle says the system must be secure even if the design is known. It does not say you are obligated to publish your design, or that hiding operational details provides zero benefit.
Researchers have argued that the blanket dismissal of obscurity-based techniques has led defenders to underuse strategies that attackers routinely exploit. Techniques like honeypots, decoy systems, address-space randomization, and moving-target defenses all involve some element of hiding information from the attacker. They work not because the attacker can never figure out the truth, but because they raise the cost and uncertainty of an attack. The argument is that these techniques have gone underappreciated by defenders, while attackers have no qualms about using deception and concealment, which creates an unfortunate imbalance.2arXiv. Effective Security by Obscurity
The key distinction is whether obscurity is the foundation or the garnish. A system that uses AES with a strong key and also hides its server’s operating system version from casual probes is not violating Kerckhoffs’s principle. It is following the principle (the core security does not depend on the hidden information) while also making life a little harder for an attacker who is probing for known vulnerabilities. A system that uses a homemade cipher and relies on no one ever seeing the code is violating the principle. The two cases are not equivalent, even though both involve hiding something.
The Open Source Connection
Kerckhoffs’s principle is one of the intellectual foundations for the argument that open-source software tends to be more secure than closed-source software, at least in the domain of cryptographic and security-critical code. If your system’s security does not depend on the secrecy of its code, then publishing the code costs you nothing in terms of security and gains you the benefit of widespread review.
This argument has an economic dimension as well. Researchers have drawn an analogy between a software vendor who keeps security-relevant code secret and a monopolist: the vendor controls information and has reduced incentive to fix weaknesses that only they can see. An open-source supplier, by contrast, operates in something closer to a competitive market, where external reviewers can identify and report flaws. This framing suggests that the choice between openness and secrecy in security is not just a technical question but also involves market incentives, and that market failures can lead to less openness than would be optimal for overall security.3arXiv. What Should be Hidden and Open in Computer Security: Lessons from Deception, the Art of War, Law, and Economic Theory
That said, the open-source security argument is not absolute. Publishing code only improves security if qualified people actually review it. The OpenSSL Heartbleed vulnerability persisted in open-source code for over two years before being discovered, despite the library being among the most widely used security-critical software on the planet. Open code is a necessary condition for broad public review, but it is not sufficient. The principle says the system should not need secrecy to be secure; it does not promise that openness automatically produces security.
What Kerckhoffs’s Principle Does Not Say
Several common misunderstandings are worth clearing up, because they lead people to apply the principle incorrectly or to dismiss it for the wrong reasons.
The principle does not say you should publish your keys. This sounds obvious, but the confusion arises when people conflate “the system” with “everything about the system including the key.” The whole point is to draw a sharp line between the system design (which should be assumed known) and the key (which must be kept secret). Anything that functions as a key, meaning a short, changeable secret whose compromise can be remedied by choosing a new one, is exactly what you should protect.
The principle does not say that all secrecy is bad. It says that the security of the cryptographic mechanism itself should not depend on secrecy. Operational secrecy, like not announcing which specific server holds your most sensitive data, or not publishing your network topology, is a different matter entirely. These are operational details, not part of the cryptographic design, and concealing them is standard good practice.
The principle does not say that proprietary systems are inherently insecure. A company can use a proprietary protocol that has been privately audited by competent third parties and still satisfy the principle in spirit, if the protocol’s security rests on key secrecy rather than algorithm secrecy. The concern is with systems whose security would collapse if the algorithm were exposed, not with systems that happen to be non-public for business reasons but are fundamentally sound.
The principle also does not say anything about authentication or access control more broadly. It is a statement about cryptographic design. People sometimes invoke it in debates about whether software should have hidden admin backdoors or undocumented access mechanisms, and while the spirit of the argument translates, the principle itself was specifically about ciphers.
How the Principle Shapes Modern Standards
Nearly every respected cryptographic standard today is designed in explicit accordance with Kerckhoffs’s principle. The AES selection process, as mentioned earlier, was fully public. The SHA-3 hash function was chosen through a similar open competition. TLS, the protocol that secures web traffic, is specified in publicly available documents down to the byte level. Anyone can read exactly how these systems work. Their security rests entirely on the mathematical difficulty of breaking them without the key.
Government agencies that set cryptographic policy enforce this principle in practice. When the U.S. National Institute of Standards and Technology (NIST) evaluates a proposed cryptographic algorithm, the algorithm must be fully specified and publicly available. “Trust us, it’s secure” is not an acceptable argument in the standardization process. This stance exists precisely because of the historical record: secret algorithms have failed too often and too badly.
The ongoing NIST post-quantum cryptography standardization effort follows the same model. Recognizing that future quantum computers could break currently standard public-key algorithms, NIST launched a public competition for quantum-resistant replacements. Candidate algorithms were published, attacked by researchers worldwide for years, and the survivors were standardized. The process assumes, per Kerckhoffs, that the attacker will know every detail of the algorithm. The only defense is mathematical strength.
Passwords and Everyday Applications
You encounter Kerckhoffs’s principle every time you log in to a website, even though you probably do not think of it that way. The hashing algorithm that protects your stored password is publicly known. The security of your account does not depend on an attacker being unable to figure out that the site uses bcrypt or Argon2. It depends on your password being hard to guess, and on the hashing algorithm being computationally expensive to brute-force. The algorithm is the system; the password is the key.
This is also why security professionals stress password strength and uniqueness rather than exotic login mechanisms. If the login system itself is well-designed and publicly vetted, the weak link is your password. A twelve-character random password protecting an account on a system using a well-known, well-studied protocol is far more secure than a four-digit PIN protecting an account on a system with a secret, proprietary login mechanism. The first system follows Kerckhoffs’s principle. The second one violates it.
The same logic applies to encryption tools you might use directly. When you encrypt a file with a tool like VeraCrypt or use an encrypted messaging app like Signal, the encryption algorithms are fully documented and open-source. Knowing that Signal uses the Signal Protocol, or that VeraCrypt uses AES-256, gives an attacker no advantage. The encryption’s strength comes from your passphrase and from the mathematical properties of the algorithm, not from its secrecy. If someone tried to sell you an encryption product but refused to tell you what algorithm it used, that would be a red flag, not a feature.
The Economics of Disclosure
One of the subtler implications of the principle touches on incentives. When a company’s product relies on a secret algorithm for its security claims, the company has a financial incentive to suppress information about weaknesses. If the algorithm is exposed and found to be flawed, the product’s value collapses. This creates a dynamic where the vendor may resist independent security research, pursue legal action against researchers who discover vulnerabilities, or quietly patch flaws without disclosing them to users.
When the algorithm is public, the incentive structure changes. The vendor cannot pretend the algorithm is stronger than it is, because anyone can test it. Weaknesses that are found get reported and fixed in the open. The vendor’s competitive advantage shifts from “we have a secret sauce” to “we implement well-studied algorithms correctly and maintain our systems responsibly.” This is a healthier dynamic for users, even if it is less comfortable for vendors who prefer to differentiate on mystery.
The economic framing also helps explain why security by obscurity persists in some industries despite its poor track record. For vendors selling to buyers who cannot independently evaluate cryptographic strength, secrecy can function as a marketing advantage. “Our proprietary algorithm” sounds impressive to a non-technical buyer. The problem only becomes visible when the algorithm is eventually broken and the buyer discovers that their expensive system was built on weak foundations. By then, the vendor has already collected payment.
Kerckhoffs’s Principle in Hardware
The principle becomes particularly interesting in the context of hardware security. Software algorithms can be updated relatively easily when flaws are found. Hardware, especially hardware embedded in millions of deployed devices, is far harder to fix. This makes adherence to Kerckhoffs’s principle even more critical in hardware design, because the cost of getting it wrong is much higher.
SIM cards, smart cards, vehicle immobilizers, and electronic passport chips all use cryptographic algorithms that are, in principle, publicly known. When manufacturers have deviated from this approach and used proprietary algorithms, the results have often been painful. Several widely deployed proprietary RFID and smart card ciphers were eventually reverse-engineered and found to have serious weaknesses. Because the hardware was already in millions of devices, the fix required physical replacement rather than a software update.
The hardware context also illustrates a genuine edge case. Even when the algorithm is public, hardware implementations can leak information through side channels like power consumption, electromagnetic emissions, or timing variations. These side-channel attacks do not break the mathematical algorithm; they exploit physical properties of the specific implementation. Defending against side channels involves a combination of algorithm-level countermeasures and implementation-level hardening, and some of the implementation details are legitimately kept confidential as an additional defensive measure. This is the “obscurity as garnish” approach described earlier: the core algorithm is public and mathematically sound, but the specific countermeasures against physical attacks add a layer of practical difficulty for attackers without serving as the primary defense.