Rule 1 of 12 · Chapter I — One Secret, Clearly Named

Put every secret your system depends on into the key, and nothing else.

Why this rule exists

A system with secrets scattered across code, configuration, protocol quirks, and hardware has no clear boundary to defend, and no clear thing to rotate when something leaks. Concentrating secrecy in the key gives you one asset to protect, one asset to audit, and one asset to replace. Diffuse secrets fail silently: you only learn an undocumented constant was load-bearing when someone publishes it.

In practice

Write down every value whose disclosure would weaken the system, then drive the list to one item: the key (or a keyed hierarchy derived from it). A hardcoded salt, a proprietary S-box, an undocumented header offset, a "private" API path — each either moves into the key, or gets published and designed around. Make the security argument readable as a single sentence: given the key, the attacker wins; without it, they don't.

When it doesn't apply

Credentials outside the cryptographic core — operator passwords, signing keys for a separate trust domain, hardware root keys burned at manufacture — are legitimately separate secrets; they still need the same naming and rotation discipline. Short-lived values like nonces and ephemeral session state are not secrets in this sense, though they have their own uniqueness requirements.