Every lock teaches the thief

There is an old vanity in engineering: wrap a thing in mathematics and call it saved. We speak of strong encryption as though it were a cathedral wall, thick enough to keep out the century. But cryptography has never been a wall. It is a bargain. It is a fine lock on a moving door in a house full of windows. The mathematics may be beautiful. That is not the same thing as final. The sober documents tell on themselves. They do not speak in the language of immortality; they speak of key management, entropy, module security, non-invasive attacks, retirement schedules, and the long history of real attacks on deployed protocols. That tone is the lesson. A cipher is only as sound as the keys that feed it, the randomness that births it, the machine that carries it, the protocol that frames it, and the calendar that will one day turn against it. Most failures are not born in the equation but in the custody. Steal the key and the theorem politely steps aside. This is why serious guidance spends so much ink on key management, and why modern storage guidance keeps repeating the same unromantic sermon: do not hard-code keys, do not toss them into source control, do not leave them lying beside the data they are supposed to protect. Separate keys from data. Wrap data-encryption keys with key-encryption keys. Treat custody as the center of the problem, because in practice it usually is. Then there is randomness, that invisible servant upon which the whole household depends. Cryptography asks for uncertainty the way bread asks for yeast. If your random bits are weak, recycled, predictable, or badly seeded, your grand design becomes theater in a velvet coat. NIST gives randomness its own standards family for a reason. Entropy is not a decorative detail. It is part of the foundation. And then the machine begins to gossip. Timing. Power draw. Error behavior. Packet shapes. Cache patterns. The body tells secrets the mind meant to keep. NIST’s own language around modern cryptography makes this plain: small devices are especially vulnerable to side-channel attacks, no algorithm is inherently immune, and FIPS 140-3 treats non-invasive security, sensitive-parameter management, self-tests, and mitigation of other attacks as first-class concerns. Even threshold cryptography is being pursued in part because splitting trust can improve robustness and help resist leakage from real implementations. The proof on paper does not stop the chip from sweating. Then comes age, that undefeated cryptanalyst. Deployed cryptography is a living thing, and living things rot around the edges. The IETF’s modern TLS guidance exists precisely because real-world TLS and DTLS suffered serious attacks over the years. NIST’s current transition draft does not hide behind ceremony either; it proposes the retirement of ECB as a confidentiality mode, the retirement of DSA for signature generation, and a schedule for retiring SHA-1. Yesterday’s respectable choice becomes tomorrow’s museum exhibit with a warning placard beside it. And time is not merely the slow decay of standards; it is also the arrival of stranger machines. NIST finalized its first three post-quantum standards in 2024 and says organizations should begin migrating now. Its transition page says quantum-vulnerable algorithms are slated to be deprecated and ultimately removed from standards by 2035, with high-risk systems moving earlier. Notice the humility again: FIPS 203 says ML-KEM is, at present, believed secure, and in 2025 NIST selected HQC as a backup in case ML-KEM is someday found wanting. NIST also warns about the “harvest now, decrypt later” problem, because some secrets outlive our forecasts. That is the real creed of cryptography. Not certainty. Contingency. Does this mean cryptography is useless? No. It means the remedy is not stronger magic. It is discipline. It is humility with a wrench in its hand. The first remedy is to stop trying to be clever in the wrong places. Custom cryptography is a vanity project with a body count. OWASP’s advice on that subject is refreshingly blunt: don’t. Use standard, well-studied constructions, and use authenticated encryption by default so confidentiality and integrity travel together rather than as estranged cousins. Boring crypto is good crypto. Boring crypto is how payroll sleeps at night. The second remedy is to move the secret out of easy reach. Separate keys from data. Use envelope encryption. Keep your most sensitive keys in hardware or cloud HSMs when the system justifies it. Shorten key lifetimes. Rotate them. Audit who can touch them. Most breaches are not tales of genius; they are tales of proximity. The third remedy is to harden the place where math becomes machinery. Use validated modules where you need high assurance; FIPS 140-3 exists because implementation security is not a footnote. For higher-stakes systems, split trust across components or parties instead of concentrating it in one sacred box. Threshold schemes are not a charm against all evil, but they are part of a sane future because they assume compromise will happen somewhere, someday. The fourth remedy is to build for change before change drags you by the ankle. Inventory everywhere your systems use cryptography. Make algorithms swappable. Introduce hybrid handshakes where they fit. The transition path is already visible: the IETF is defining hybrid TLS key exchange so the shared secret can remain secure as long as one component remains unbroken; Cloudflare has deployed hybrid X25519-plus-ML-KEM support to origin connections; Signal first added PQXDH and then post-quantum ratchets so it could preserve forward secrecy and post-compromise security in a quantum future. The lesson is not that salvation has arrived. The lesson is that serious people migrate early. And perhaps the most old-fashioned remedy of all is this: keep less. The data you do not retain cannot be stolen later, decrypted later, extorted later, or quietly copied into someone else’s century. Security people forget this because it lacks glamour. But deletion is sometimes the cleanest cryptographic primitive ever invented. So when I say cryptography is never secure, I do not mean it is fraudulent. I mean it is mortal. It is secure only under assumptions, only for a season, only with care, only against known enemies, only until a clerk misconfigures the server, a developer logs the wrong thing, a vendor ships a downgrade, a side channel whispers, or the future arrives carrying a better crowbar. That sounds bleak. I take it as consolation. We are freed, then, from the childish dream of perfect secrecy. What remains is better: honest design, smaller blast radii, shorter trust, cleaner protocols, stronger custody, faster migration, less retained data, and enough humility to know that every lock, once made, begins teaching the thief.