Cryptography without shortcuts
Pick primitives by job, build authenticated records, rotate keys, run TLS, plan post-quantum migration, then study past failures.
- Connect historical failures to distinct confidentiality, integrity and key-generation properties.
- Design authenticated records and key/certificate lifecycle decisions without relying on algorithm names alone.
- Explain nonce uniqueness across concurrency, restart and key identity.
- Be comfortable with bytes, equality, simple arithmetic and the idea of a secret key.
- Historical examples are conceptual case studies; no attack infrastructure or cryptographic implementation is required.
Estimated time: about 5–6 hours across 12 steps, including 2 browser labs and 1 local project.
By the end: A property-and-lifecycle notebook plus a tested nonce-allocation repair; conclusions remain specific to the supplied mechanisms.
0 of 12 steps complete
Use the guide's job table to pick the algorithm, parameters and library call for encryption, hashing, MACs, password storage, signatures and key agreement in one service you know, then review that service's cryptographic calls against your choices.
Keep: A one-page crypto profile: each job the service performs, with its primitive, parameters and API call.
Complete when: Every cryptographic call in the service maps to a row of the profile, and each weak or misused primitive the review found has an owner and a replacement.
Open guide : Choose cryptographic algorithms and parameters by jobRun the insecure randomness lab: replace Math.random with the supplied secure byte source, map bytes onto the alphabet with the discard rule, and loop until the key has 32 characters.
Keep: A repaired key generator with the lab's passing cases.
Complete when: Every character comes from the generator's bytes, bytes 248 to 255 are discarded, and keys have about 190 bits.
Open lab : Insecure randomness lab: Generate unguessable API keysTrace the record fields, nonce, key identifier and associated data through the guide’s accept/reject cases.
Keep: A record contract with exact authentication and nonce assumptions.
Complete when: Identify which modifications fail authentication and which required context must be bound explicitly; confidentiality and replay handling remain distinct.
Open guide : AEAD records: AES-GCM nonces, associated data and key limitsRun the nonce lab through restarts, competing writers, aliases for the same key and exhaustion. Relate each result to the AEAD record contract.
Keep: A tested allocator and a four-case uniqueness explanation.
Complete when: No successful allocation repeats a key–nonce pair under the lab’s contract; safe refusal at exhaustion is distinguished from an allocator that simply never works.
Open lab : AES-GCM nonce reuse lab: Fix a nonce allocator that breaks after restartDownload the encrypted records project, run node --test exercise.test.mjs, then bind version, tenant, record ID and purpose in recordContext.
Keep: Your context encoding, with a note on why no two different records can produce the same bytes.
Complete when: All ten tests pass, including the cross-tenant transplant and boundary-collision cases.
Open project : Bind ciphertext to the correct recordApply the supplied rotation states to reads, new writes, interrupted work and recovery.
Keep: A key/version transition table with rollback and retirement conditions.
Complete when: Distinguish rewrapping a data key from re-encrypting payloads and refuse to retire a key while required records still depend on it.
Open guide : Envelope encryption and key rotation: data keys, KMS keys and backupsEvaluate the supplied certificate/trust cases and map the renewal process to clients and long-lived connections.
Keep: A TLS trust and renewal test record.
Complete when: A valid chain is not substituted for the expected endpoint identity, and a renewed file is not assumed active until the relevant service/client path is checked.
Open guide : Operate TLS and certificates: configuration, renewal and verificationUse the inventory fixture to connect algorithms with protocol, library, key, certificate, owner and data-lifetime dependencies.
Keep: A migration priority and compatibility record.
Complete when: Explain which dependency must change first and why an algorithm label alone cannot prove end-to-end migration.
Open guide : Post-quantum migration: cryptographic inventory, hybrid TLS and deadlinesCompare the guide’s repeated-block observations and separate recovery of a pattern from recovery of full plaintext.
Keep: A confidentiality claim stating exactly what the observer learns.
Complete when: Explain the equality leak and why replacing visible formatting does not establish a secure encryption construction.
Open guide : ECB mode: why it leaks patterns and what to use insteadTrace the supplied ciphertext/error interaction and identify which observable distinction carries information.
Keep: An oracle diagram and a proposed failure-handling boundary.
Complete when: Explain why uniform-looking output alone may be incomplete when timing or another path still distinguishes failures.
Open guide : Padding oracle attacksWork the guide’s collision/signature example and identify which assumption a same-digest pair invalidates.
Keep: A comparison of collision, preimage and signature-verification claims.
Complete when: Do not infer that any chosen existing message can be forged merely because collisions exist; state the actual scenario’s attacker capability.
Open guide : Hash collisions and digital signatures: MD5, SHA-1 and what to useUse the supplied weak-generation evidence to identify the affected key population and what replacement must invalidate.
Keep: A key-generation failure and recovery record.
Complete when: Explain why changing a label or certificate without replacing the weak private key does not repair the underlying failure.
Open guide : Weak RSA key generation: shared primes, ROCA and safe keysRotate a key without losing or transplanting records
Use the complete synthetic fixture below in a notebook or text file. No live target, paid service or secret is needed. Make your own decision before opening the worked assessment. Then take the implementation option below, a local project in which you repair running code until its tests pass, and keep its test output with your written answers.
A document service is replacing a compromised wrapping key. Decide which operations are safe and design evidence for migration and recovery.
Supplied material
Record contract: AES-GCM with an opaque random data key per document; each encryption requires a fresh nonce under that data key. Associated data is canonical encoding of tenant ID, document ID and record schema version. The data key is wrapped by a KMS key.
R1: tenant north, document 7, schema 2, wrapping key K-old, data key D1, nonce N1, ciphertext C1.
R2: tenant south, document 7, schema 2, wrapping key K-old, data key D2, nonce N2, ciphertext C2.
Migration M1: unwrap D1 and rewrap the same D1 under K-new; leave C1 and its encryption nonce unchanged.
Migration M2: edit R1 plaintext, encrypt again using D1 and N1.
Migration M3: copy C1 into R2 and replace the visible tenant field with south.
Backup B from Monday contains K-old-wrapped data keys. Current data has all been rewrapped, but B has not been restore-tested.
Threat update: the K-old wrapping credential was exposed; whether plaintext data keys were extracted is unknown. K-old remains enabled for a seven-day overlap.
Legacy client L negotiates an obsolete cipher suite; its certificate uses the same private key as a second forgotten endpoint.Work through the case
Classify M1–M3 as allowed or rejected under the record contract and explain which cryptographic input changes.
Draw a rotation state machine covering new writes, reads during overlap, retry-safe migration and retirement.
Separate wrapping-key compromise from possible data-key compromise, and describe what evidence changes the rewrap-versus-reencrypt decision.
Write backup restoration and shared-TLS-key discovery tests before authorizing deletion or retirement.
Decide the fixed cases
These parts of the case have one right answer, taken from the worked assessment. Check them here; the rubric below assesses your written reasoning. The capstone meets the bar when every decision is right and the self-check reaches it.
Is each migration allowed under the record contract?
Decide the key questions.
Evidence to retain
- Operation decision table with key/nonce/AAD reasoning.
- Migration ledger with old/new key IDs, document identity and completed verification.
- Compromise assessment and backup restore acceptance criteria.
- Legacy endpoint inventory and ownership record.
Assess your work
Score each criterion with the anchor whose evidence your answer shows: 0, 1 or 2 points. Every anchor describes something a reviewer can point to in your work. Aim for at least 7 of 8, with no unresolved critical failure.
Score your answer against the anchors
Choose the anchor that matches your answer for each criterion.
Recorded checks stay in this browser only, so you can compare attempts. This is a self-assessment, not a certification.
Compare with the worked assessment
M1 is rewrapping, so it need not re-encrypt C1 and does not reuse a nonce for a new encryption. M2 violates uniqueness by encrypting new plaintext under D1,N1. M3 fails when decryption authenticates the expected south/7/schema-2 context; trusting attacker-supplied context would defeat the binding. Rewrap does not undo disclosure of D1 or plaintext; proven or plausible data-key compromise requires a separately assessed data re-encryption/incident response plan. Keep the old unwrap capability only as tightly scoped and time-bounded as recovery requires. Do not delete K-old until retained backups have a verified restoration or migration path. Inspect every endpoint using the shared TLS key, not only L.
Save a draft on this device to resume later. Automatic saving begins after you choose Save. Drafts are never sent by this application; use synthetic data.
No draft saved on this device yet.
Implementation option: Bind ciphertext to the correct record
Repair authenticated context binding in exercise.mjs until all 10 tests pass, then add a test that reproduces migration M3: ciphertext copied from one tenant’s record into another’s.
Keep: Failing and passing test output, and the added M3 test with the associated data it expects.
Node.js 22+ · no dependencies · 30–45 min · 10 tests
Identity through the whole lifecycle
Connect login, token verification, phishing-resistant credentials, recovery and authorization to testable boundaries.
Your progress, your browser
Progress is stored on this device. Export it to carry it to another browser, or clear it whenever you want. Importing a file adds its completed items to the progress already here; items this site no longer offers are skipped and counted, and nothing else is removed.