Cryptography You Will Actually Use

An application engineer who tries to design a new cipher, a new hash construction, or a novel way of combining existing primitives is not being ambitious — they are recreating decades of published cryptanalysis with none of the review that caught the flaws in every serious cryptographer's early drafts too. The skill this lesson actually teaches is narrower and more useful than "understand cryptography": recognize which of a small number of vetted, off-the-shelf constructions solves the problem in front of you, and use it correctly, because correct use of a vetted primitive is where nearly all real-world cryptographic failures actually happen — not in the primitive itself.

This lesson is deliberately a menu, not a mathematics course. For integrity, you reach for a cryptographic hash. For proving a message came from someone holding a shared secret and wasn't altered in transit, you reach for an HMAC — a construction this course has already used repeatedly for webhook and CSRF verification, precisely because it is the vetted answer to that exact problem. For storing a password, you reach for a slow, adaptive key-derivation function, never a fast general-purpose hash. For encrypting data such that both confidentiality and integrity are guaranteed together, you reach for an authenticated encryption construction. None of these choices require you to understand the number theory underneath them to use correctly — they require you to know which one answers which question.

The recurring failure this lesson exists to prevent is a fast general-purpose hash (MD5, SHA-256 alone) being reached for as if it were a password-storage function, or a raw block cipher being used without the authentication that catches tampering — both are cases of a real, sound primitive being misapplied to a job it was never designed for, which is a use error, not a flaw in the primitive.

Analogy🏏Cricket

🏏 Think of it like cricket: A physiotherapist treating a fast bowler's recurring niggle does not attempt to design a new muscle-recovery protocol from first principles for every player — that would mean re-deriving decades of sports-medicine research with none of the peer review, controlled trials, or accumulated clinical evidence that makes an established protocol trustworthy in the first place. What an experienced physio actually does is diagnose which established, evidence-based protocol fits the specific injury — a hamstring strain gets a different vetted rehabilitation pathway than a stress fracture, and the physio's real expertise is correctly identifying which protocol applies, not inventing a new one. A physio who improvised a recovery plan from intuition alone, however well-intentioned, would be gambling a professional athlete's career on an untested approach when a proven one already existed for exactly this injury. Just as an experienced physio selects the right established protocol rather than designing a new one, an application engineer selects the right vetted cryptographic construction rather than designing a new one. Just as correctly diagnosing which protocol fits the injury is the actual skill, correctly identifying which vetted primitive answers your specific problem — integrity, authentication, confidentiality, password storage — is the actual skill this lesson teaches. The insight is that expertise in a high-stakes field is usually about selecting correctly from what's already been rigorously proven, not about improvising something new under pressure.