Exercise 2: Why a Secret Algorithm Is a Red Flag — Possible Solution ==================================================================== Kerckhoffs's Principle states that a cryptographic system should stay secure even if everything about it EXCEPT THE KEY is public knowledge. A company relying on secrecy of its own algorithm's design is doing the opposite — betting the system's security on something (the algorithm) that the principle says should be assumed to leak sooner or later, rather than on something (the key) that's actually designed to be kept secret and rotated. Why this is a red flag rather than good practice: 1. NO OUTSIDE REVIEW. A secret, unpublished algorithm has only been scrutinized by the small team that built it. Published algorithms like AES have been attacked for decades by the world's best cryptanalysts and have held up — that sustained public attack IS the evidence of real strength. A secret algorithm has no equivalent evidence behind it; it's untested by anyone with an incentive to break it. 2. SECRECY DOESN'T SURVIVE CONTACT WITH REALITY. Algorithms get reverse-engineered from compiled binaries, leaked by employees, or exposed through a data breach. The moment that happens, a system built on "the algorithm's design is secret" loses its only line of defense at once — there's no key to simply rotate, because the flaw was in the design itself, not a compromised key. 3. IT'S USUALLY HIDING WEAKNESS, NOT ADDING STRENGTH. In cryptographic engineering, refusing to publish an algorithm is treated as a strong signal that it wouldn't survive public scrutiny — a genuinely well-designed algorithm has nothing to lose by being published, since Kerckhoffs's Principle says its security should never have depended on secrecy in the first place. The right approach — what AES, RSA, and every algorithm covered later in this course actually do — is to publish the algorithm openly and rely entirely on the secrecy of the key, exactly as Kerckhoffs described in 1883.