Crypto Lab

Hand-out · Post-quantum transition

Post-quantum transition: worksheets

Every worksheet in this module, in the order the sequence runs them. Each one starts on its own page when printed.

Back to the module

Shor

Exhibit
Shor live exhibit: https://systemslibrarian.github.io/crypto-lab-shor/
Time
About 18 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 66c0e3109427 on 2026-09-22

Predict

Answer these before you open the exhibit. There are no penalties for wrong predictions; the point is to compare them with what you see.

  1. You are going to run the same N three times. For each of these, predict whether it stays the same across your three runs or changes: the base a, the period r, the register size Q, and the two factors printed on the result line. Write your predictions in the first column of the first table under Record.
  2. The page's first explainer turns a^r ≡ 1 (mod N) into (a^(r/2) − 1)(a^(r/2) + 1) ≡ 0 (mod N) and then takes a gcd of each half with N. That chain needs the period r to be even. Predict what a run should do when the period it recovers is odd: stop and report failure, print a factor anyway, or something else.
  3. Each attempt picks a base a at random from 2 to N−1. Predict what should happen when that base happens to share a factor with N, before any quantum step runs. Would you call that outcome a success or a failure of the run?
  4. The quantum measurement is a sample from a probability distribution, not a lookup. Predict whether two attempts using the same base a, and therefore the same period r, could still measure different frequencies m — and whether both could still end with the same r.

Do

  1. Open the exhibit. Before pressing anything, read the note under the controls: it says Shor is randomized, that each run picks a fresh base a, and that a run can fail and retry. Then read the first explainer, Why does the period r let you factor N?, which stays open at the top of the page.
  2. In the Presets row, press 91. A preset fills the Factor N field and starts the run by itself — you do not also press Run Shor's Algorithm. Watch the ALGORITHM STEPS log fill from the top.
  3. When the run stops, find the Resource estimate line near the top of the log and copy the register size Q and the logical qubit count it states into the second table. You read this line once; later runs of N = 91 restate it.
  4. Fill the first row of the third table from this run: the base a and the period r from the This run: line inside the first explainer; Attempts and the two factors from the RESULT line at the foot of the log; and, in the last column, every line that begins ↺ Retrying: together with the reason it names.
  5. Press Run Shor's Algorithm and record a second run the same way, then a third. Record each run before you start the next one — a new run clears the log and the PERIOD TABLE / QFT VISUALIZATION panel.
  6. Some runs end differently, and each of those is a row to fill in rather than a mistake. If the This run: line keeps its italic placeholder and the PERIOD TABLE / QFT VISUALIZATION panel says the run drew a base that already shared a factor with N, write "lucky gcd, no period" in the last column and copy the factor the log's Lucky GCD line reports. If the log prints one or more ↺ Retrying: lines and then carries on, record every reason it names. If a stage banner reads Stage 3 — no convergent denominator satisfied a^r ≡ 1, so the period was NOT recovered, record that alongside the retry reason.
  7. Pick one of your runs that did reach a period, and copy its This run: chain into the fourth table, number by number: the base, the period, a^(r/2) mod N, both gcds, and the check it prints at the end.

Record

Every value in the second, third and fourth tables comes from your own run.

ValueSame across runs, or changes? (predicted)What my three runs showed
Base a
Period r
Register size Q
The two factors on the RESULT line
From the Resource estimate line, for N = 91Value
Register size Q
Logical qubits
RunBase aPeriod rAttemptsFactors on the RESULT lineRetry reasons, or how else the run ended
First run
Second run
Third run
From the This run: line of one run that reached a periodValue
Base a
Period r
a^(r/2) mod N
gcd(a^(r/2) − 1, N)
gcd(a^(r/2) + 1, N)
The check it prints

Explain

  1. Match your fourth table line by line to the four numbered steps of the first explainer, Why does the period r let you factor N? Why does that chain need r to be even, and what does the demo do with an attempt whose period is odd — answer from your own log if one of your runs showed it, otherwise from the third step of the explainer's chain. What do your two gcds multiply to, and what does the Verification clause of the log's Factors found line check?
  2. Compare your three rows. Which values changed from run to run and which did not? The Resource estimate line states how Q is built — use its wording to say what Q depends on, and why the base a and the period r do not behave the same way across runs.
  3. Take one run that retried, that needed more than one attempt, or that ended with no period at all. Using the reason the log names, say what that attempt had drawn or measured, and why drawing a fresh base is part of the method rather than an error. If the retry pushed the Attempts count up, say what else appeared in the log at that moment; if the count did not move, say what that tells you about where in the attempt the retry happened. If none of your runs did any of this, use a classmate's.
  4. The explainer closes by saying the quantum computer's only job is finding r, and that everything else in the chain is ordinary arithmetic. Using your own log, name one step of your run that a quantum computer would perform and one that it would not, and say which words on the page told you which was which.

Fix / Extend

  1. Fix. A service establishes its keys with RSA-2048 and encrypts the data itself with AES-256. Using the QUANTUM-RESISTANT AFTER SHOR list and the RESOURCE REQUIREMENTS table in the RSA IMPACT panel, say which of those two the page puts on its broken list and which it leaves usable, what that table gives as the logical-qubit estimate for the broken one, and which of the replacements named on the page you would put in its place. The call-out at the foot of that panel links one of them.
  2. Extend. After a run that reached a QFT visualization, scroll the PERIOD TABLE / QFT VISUALIZATION panel to the block headed Phasor wheels — why the peaks form (classically simulated). Its frequency buttons are built by the run, so their labels carry your own run's numbers: press the one whose label begins off-peak and record the Σ value under the summed wheel and whether the page calls it add or cancel; then press the one whose label begins on-peak and record the same two. Using the second explainer, Why does the QFT concentrate at multiples of Q/r?, explain why one frequency gives a long resultant and the other a short one, and what that has to do with the tall bars in the distribution chart above it.
  3. Extend. Press Reset, then the preset 15, and let three runs go by. Record the register size Q and the logical qubit count from the Resource estimate line for N = 15 and compare them with the pair you wrote down for N = 91. How many of your three runs reached a QFT visualization at all, and what did the PERIOD TABLE / QFT VISUALIZATION panel say for the ones that did not?
  4. Extend. Type 97 into the Factor N field and press Run Shor's Algorithm, then do the same with an even number such as 100. Record the banner each one produces and what the PERIOD TABLE / QFT VISUALIZATION panel says. Using the Pre-check line that N = 91 printed, list what the demo tests about N before it would draw a base at all, and say which test each of your two inputs failed.
  5. Extend. In the PERIOD TABLE / QFT VISUALIZATION panel, find the Continued Fraction Extraction section for one attempt and read its caption and its table. Which row is marked ← the period r, and what test does the third column apply to each denominator? Using the caption, explain why the demo tests the denominators rather than trusting the first one it computes.

Grover

Exhibit
Grover live exhibit: https://systemslibrarian.github.io/crypto-lab-grover/
Time
About 26 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 873e40d8f891 on 2026-09-22

Predict

Answer these before you open the exhibit. There are no penalties for wrong predictions; the point is to compare them with what you see.

  1. A search space holds 16 keys and exactly one of them is correct. Classically, how many keys would you expect to try before you hit it? Grover's search needs roughly the square root of the space instead. Write down the number of Grover iterations you expect, and say which of the two numbers you are more confident about.
  2. Grover's oracle recognises the correct key and flips the sign of its amplitude — it turns a positive number negative. Predict what that does to the probability of measuring the correct key at that instant: raises it, lowers it, or leaves it alone. Give a reason before you look.
  3. You keep pressing Step long after the amplitude has climbed. Predict what the success probability does: keeps rising, levels off at some ceiling, or falls again. Sketch the shape you expect on a graph of probability against iteration count.
  4. Grover is usually summarised as "it halves your effective key length". Predict what AES-128 and AES-256 become under that rule, and predict whether a halved key length is the same thing as a broken cipher. Then predict which of AES-256 and RSA-2048 the page will say needs a bigger parameter and which needs a different algorithm.

Do

The exhibit is one long page of panels, not tabs. Each step names the panel heading to scroll to.

  1. In the Grover's Algorithm — Amplitude Amplification panel, leave Search space n qubits at 4. Record the N readout beside the slider, the index and binary label on the target line, and the two numbers on the iteration line, which reads Iteration: k = 0 / k* = 3. Scroll to Classical vs Quantum Search and record the three numbers in the two strategy blocks: the classical expected queries, the Grover oracle queries, and the reflections applied. Fill in the first table.
  2. Back in Grover's Algorithm — Amplitude Amplification, check Show oracle + diffusion sub-steps. A sub-step line appears under the iteration line reading State — equal-ish superposition after the last iteration. Record the target amplitude and the probability from the amplitude readout beside the bar chart, and whether the target's bar sits above or below the centre line.
  3. Press Step once. The sub-step line now reads Oracle — flip the target’s phase. Record the same three things again. Press Step a second time; the line reads Diffusion — invert all amplitudes about the mean. Record the same three things a third time. Fill in the second table.
  4. Press Reset, uncheck Show oracle + diffusion sub-steps, and check Prediction mode. Press Step: instead of advancing, the page asks you to commit a guess and offers three answers. Write your guess in the third table, then choose the matching answer. Read the verdict line and record what the page says actually happened, with the two percentages it prints. After each commit, glance at the probability curve below the charts and find the moving dot. Repeat until the gold banner appears reporting that the optimal k* has been reached.
  5. Press Measure ×100 and record the hit count, the empirical success and the theoretical figure in the fourth table.
  6. Press Step once more. The prompt now says you are at or past k*; commit a guess and record the verdict in the last row of the third table. The banner should change. Press Measure ×100 again and record the second row of the fourth table.
  7. Scroll to Why Grover Still Doesn't Break AES Instantly. Set Key size to AES-128 and record the classical and Grover figures; set it to AES-256 and record the same two. Fill in the fifth table.
  8. Scroll to The Real Cost of One Oracle Call. This panel has its own Key size control, and it does not follow the one in the panel above. Set it to AES-128 and record the iterations, the cost per oracle call, the total circuit depth and the practical threat; then set it to AES-256 and record the same four. Fill in the sixth table.

Record

Everything here comes from your own run. Only the target line in the first table and the hit counts in the fourth are yours alone; every other cell should match your neighbour's, and Explain 3 asks you to check that.

ReadingMy value
N
Target index, and its binary label
Optimal iterations k*
Classical expected queries
Grover oracle queries
Reflections applied
Sub-stepTarget amplitudeSuccess probabilityTarget bar above or below the centre line
State, before the oracle
Oracle
Diffusion
StepMy predictionWhat the page reportedProbability before and after
k = 0 to k = 1
k = 1 to k = 2
k = 2 to k = 3
k = 3 to k = 4
Measured atTarget hits out of 100Empirical successTheoretical
k = k*
k = k* + 1
Key sizeClassical brute forceGrover (idealized)
AES-128
AES-256
Key sizeGrover iterationsCost per oracle callTotal circuit depthPractical threat
AES-128
AES-256

Explain

  1. In your second table, the oracle changed the sign of the target amplitude. Did your probability column change across that row? Using the Reality line the Myth and Reality panel shows during the oracle sub-step, and the relationship the amplitude readout prints between an amplitude and a probability, explain what the oracle did and what it did not do. Then say what the diffusion row changed that the oracle row did not.
  2. Describe in one sentence how the probability moved across the four rows of your third table. The rotation view's caption says the state is a unit vector, that each iteration rotates it by 2θ toward the target axis, and that success probability is the squared height. Use that to explain why your last step lowered the probability rather than raising it.
  3. Your two measurement rows were taken from two different states. Compare each empirical success against the theoretical figure printed beside it, and compare your figures with a classmate's. Using the caption beside the Measure ×100 button, explain why running Grover to k* is not the same as knowing the key, and why your hit count is not your classmate's.
  4. Both key sizes in your sixth table have their iteration count set at half the key length, yet the page calls one of them weakened and the other strong. Look at which of the three cost figures changes between your two rows and which stays the same. Use that to explain both the halving and the difference in verdict. Then read The Mitigation in the Impact on Symmetric Cryptography panel: what does it say fixes the symmetric case, and what does it say public-key systems need instead? Say which of those two claims you saw evidence for in this exhibit and which one the page only asserts.
  5. The About This Demo panel lists, under This demo is not, several things the simulation leaves out. Name the item on that list that most limits what your sixth table can tell you about a real attack, and say why.

Fix / Extend

  1. Fix. You run a service that encrypts stored records with AES-128 and authenticates them with HMAC-SHA-256, and you are asked what to change for a post-quantum threat model. Using The Mitigation list in the Impact on Symmetric Cryptography panel and the hash table above it, name the parameter changes the page supports and say, from your own sixth table, what each one buys. Then use the note printed under the hash table to say which hash property the halving rule applies to and which one it does not.
  2. Extend. In the Grover's Algorithm — Amplitude Amplification panel, move Search space n qubits to 8 and record N and k from the readouts; then move it to 12 and record them again. Above 8 qubits the bar chart is replaced by a note saying the space is too large to draw individual bars; the rotation view and the probability curve keep working. Alongside each pair write the square root of N. Compare how k grows against how N grows, and say whether the growth you recorded looks like N or like the square root of N.
  3. Extend. With the slider back at 4, press Reset, then press Random target several times and watch the target line, the iteration line and the amplitude readout. Record which of those three change and which do not. The math layer under the two charts prints the equations for θ and for the success probability with the current numbers substituted; use them to explain what the probability depends on.
  4. Extend. In the Impact on Symmetric Cryptography panel, open the disclosure Grover vs Shor — The Two Quantum Threats and read its seven rows. For each row, mark whether this exhibit showed you evidence for it or only stated it. Keep the marked table: the companion Shor exhibit covers the rows this one only states.
  5. Extend. Work the Challenge Mode panel as an exit ticket. Answer all of its questions, read each explanation, and note any question whose explanation disagrees with what you recorded above.

Lattice Gentle

Exhibit
Lattice Gentle live exhibit: https://systemslibrarian.github.io/crypto-lab-lattice-gentle/
Time
About 33 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 893db9f6f046 on 2026-09-22

Predict

Answer these before you open the exhibit. There are no penalties for wrong predictions; the point is to compare them with what you see.

  1. One grid of dots can be described by more than one pair of arrows. Basis B has short arrows, basis B′ has long ones, and both describe the same dots. Decoding a target point means writing it in the current arrows' coordinates and rounding those coordinates to whole numbers. Predict which description decodes the target closer, or whether the two must tie because the dots are the same, and give your reason in one sentence.
  2. Now think about the shortest arrow you could draw from one dot of that grid to another. If the short-arrow description is swapped for the long-arrow one, predict whether that shortest vector changes, and predict whether it becomes harder to find. Those are two separate questions — answer both.
  3. One exhibit hands you a system b = A·s + e (mod 47) in which every entry of the error e lies between −2 and 2, and lets you compute A·s for any candidate s you type. Predict how you would recognise the right s, and predict what b − A·s looks like when s is wrong by only a little.
  4. The toy-Kyber panel runs at q = 137 and decrypts correctly while its decryption error stays under q/4. Predict what you will see as that error grows past the ceiling: a warning first, some message bits flipping, or an error message in place of a plaintext.

Do

Steps 1 and 2 are in the page header and the progress rail. Every step after that names the rail button that opens it, so you always know which guided step you are in.

  1. Open the exhibit. The experiment in the header asks which of two descriptions of one grid decodes the target t = (9, 2) closer. Press the button that matches your answer to Predict 1: B decodes closer, B′ decodes closer, or Same dots — they must tie. Fill in the first Record table from the sentence the page then computes.
  2. Check that Guided is the selected reading mode, then press 1 · Basis on the progress rail.
  3. In Exhibit 1, press Good basis B (Ex 2.24). Record its row of the second table: the status line under the picture (same lattice, or different), the point the rounding lands on, the error, and the badge at the end of the decoding line.
  4. Press Bad basis B′ (Ex 2.24) and record that row the same way. The two presets decode the same target, so what changed between your two rows is the description.
  5. Press Good basis B (Ex 2.24) again. Now set target x to 9 and target y to 2, typing each value and pressing Tab to commit it. Record that row — this is the target the header experiment used.
  6. Leave the target where it is and set b₁ x to 4. Record what the status line says now and what appears among the dots. Then press Good basis B (Ex 2.24) to put both the basis and the target back.
  7. Press 2 · SVP/CVP. The panel asks its own prediction first: press Predict: yes, it changes or Predict: no, it stays to match your answer to Predict 2, and read the reply. Then press Good basis B₂ = (2,0), (0,1) and Bad basis B₃ = (−2,−2), (4,3) in turn, recording a row of the third table for each.
  8. Press 3 · Reduce. Press Gauss — Ex 9.11, then press Step twice, recording ‖v‖² from each line as it appears. Press Run to end and record the last line and the count in the status line.
  9. Press 4 · LWE & SIS and stay in the first panel, LWE. Record the row the panel already shows for the candidate it opens with. Then open the LWE panel's Stuck? Reveal the known solutions disclosure, press A wrong guess: s = (1, 2, 3), and record that row.
  10. Still in the LWE panel, press Solution 1: s = (2, 15, 12) and record its row, including how many of the five table rows report a small error. Then change s3 to one more than the value that button set, press Tab, and record the last row.
  11. Press 5 · Schemes and stay in the first panel, toy-Kyber, with Worked example from the slides selected. Fill in the worked-example column of the fifth table from the decryption panel: the message bits, the decoded bits, the measured error, the ceiling the page prints, and the badge on that line. Record the Experiment seed value as well.
  12. Focus the error-bound slider in that same decryption panel — its label begins Error bound η for the sampled e₁, e₂ — and press the Right arrow key one step at a time, watching the measured-error line after each press. Stop at the first setting where the badge reports the error is over the ceiling, and fill in the second column of the fifth table, including which of the toy-Kyber panel's two mode buttons — Worked example from the slides or Fresh seeded keys — is now shown as selected. If the badge has not changed by the time the slider stops moving, press Reroll seed in the toy-Kyber panel and work up from the bottom again.
  13. Open the disclosure headed The KEM layer: Fujisaki–Okamoto with implicit rejection, live at the foot of the toy-Kyber panel. Press Run KEM: encapsulate → decapsulate and record its row of the last table, then press Tamper with the ciphertext, then decapsulate and record that row.

Record

Every value here comes from your own run.

Header experimentWhat the page computed
Where rounding in B lands
B's error
Where rounding in B′ lands
B′'s error
How much bigger the page says B′'s miss is
Exhibit 1 rowStatus line: same lattice or differentRounded decodeErrorBadge on the decoding line
Good basis B, target as the preset sets it
Bad basis B′, target as the preset sets it
Good basis B, target (9, 2)
b₁ x set to 4, target (9, 2)
Exhibit 2 basisShortest vector reportedIts length‖b₁‖‖b₂‖What the badge says
Good basis B₂
Bad basis B₃
Exhibit 3, Gauss on Example 9.11Value
‖v‖² in the first line
‖v‖² in the second line
The reduced basis in the last line
What the last line says the first vector attains
Recorded steps counted in the status line
LWE candidate sError size ‖e‖∞ reportedAccepted or rejectedRows reporting a small error
The candidate the panel opens with
(1, 2, 3)
Solution 1
Solution 1 with s3 raised by one
toy-Kyber readingWorked example from the slidesAt the first setting over the ceiling
Message bits sent
Decoded bits
Measured error ‖E‖∞
Ceiling the page prints
Badge on the measured-error line
Experiment seed
Error-bound setting
Mode button shown as selected
KEM actionDo the two keys agree?What the teaching view says happened
Run KEM: encapsulate → decapsulate
Tamper with the ciphertext, then decapsulate

Explain

  1. Your first two Exhibit 1 rows decode the same target, and the status line said the same thing about the dots in both. Using the decoding line the page prints — the target written as c₁·b₁ + c₂·b₂, then each coefficient rounded — explain why the rounded point moved when only the description changed, and why the error grew.
  2. Look at the badge column of the second table. Did rounding land on the point the page calls the true closest in every row? Using the page's own description of this decoding as the Closest Vector Problem solved the naive way, say what rounding gives you and what it does not, and which of your rows is the evidence.
  3. In the third table the shortest vector reported did not move when you switched bases, but the two badges disagreed about the basis. Explain what that says about which facts belong to the grid of dots and which belong to the description, and say what the page means when it still calls one of the two bases good.
  4. In the LWE panel, checking a candidate took one press and the page showed both sides of every equation. Using the panel's own note that the same system without the error term is solved instantly by Gaussian elimination, and the panel's disclosure on where the lattice in LWE is, explain why checking a candidate is easy while finding one is not, and name the exhibit you already did that the disclosure points back to.
  5. Use your last two tables together. First, say what actually crossed what when the decoded bits stopped matching the message, quoting the two numbers on the measured-error line rather than the slider setting — the slider's label says which of the two decides. Then say what the receiver did with the tampered ciphertext, and why the page describes that as specified behaviour rather than a failure.

Fix / Extend

  1. Fix. A colleague's slide says: "ML-KEM's private key is a secret good basis, and the receiver decodes the ciphertext with it." Using the opening card's paragraph on holding the basis intuition loosely, the key-generation note in the toy-Kyber panel, and the page's closing section on what is real here, say what is wrong with that sentence, what the secret actually is, and which part of the geometry you worked through is intuition rather than mechanism.
  2. Extend. Press 4 · LWE & SIS and go to the second panel, SIS. Open its Stuck? Reveal the known solutions disclosure and press The cheat: z = 0; record which of the three conditions the panel reports pass and which fail. Press Solution 1: z = (2, -2, 0, 3, 0) and record the three again. Then set z1 to 1, press Tab, and record which condition flips. Finally, read the two disclosures headed with the question of where the lattice is, one in each panel, and write one sentence saying which of the shortest-vector and closest-vector problems each panel is.
  3. Extend. Press 3 · Reduce and press LLL — Ex 9.21 (4-dimensional). Press Step through the whole run, writing down each Lovász line as holding or violated and noting where a swap follows one. Press Run to end and record the reduced basis and the number of swaps the last line reports. Then press Gauss — Ex 9.12 (big numbers) and Run to end, and record ‖v‖² in the first line and in the last, and how many iterations the run took compared with the number the panel's introduction states.
  4. Extend. Press 5 · Schemes and go to the second panel, toy-Dilithium. Press Replay the slides’ worked example, then Verify, and record the two check lines and the verdict. Press Tamper with z, then verify and record what changed. Then type a short message of your own into Message to sign:, press Sign (live, with rejection sampling), and record how many attempts the page lists and how many of them were aborted and why. Press Verify, then Verify against a tampered message, and record both verdicts together with what the page says about how often a tampered message can still be accepted at this toy size.
  5. Extend. Press 6 · Check and answer all five questions, choosing before you read any explanation. Record your first-try score, and for each question you missed write one line saying what the page's explanation gave you that your answer did not.

Kyber Vault

Exhibit
Kyber Vault live exhibit: https://systemslibrarian.github.io/crypto-lab-kyber-vault/
Time
About 20 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 3f80e2eaa9c9 on 2026-09-22

Predict

Answer these before you open the exhibit. There are no penalties for wrong predictions; the point is to compare them with what you see.

  1. In this exhibit Bob runs KeyGen, Alice runs Encaps, and Bob runs Decaps. Of Bob's private key, Bob's public key, the ciphertext and the shared secret, predict which one has to cross the wire for both sides to end up holding the same bytes, and which one never crosses it at all.
  2. The exhibit calls this a key encapsulation mechanism rather than public-key encryption. Predict whether you will get to choose the secret Alice sends, and say what you think would have to be added before a sentence of your own could be sent.
  3. A button labelled Tamper with ML-KEM ciphertext flips part of the ciphertext before Bob decapsulates. Predict what Bob's decapsulation does: report an error, hand Bob a different secret, or hand Bob the same secret. Then predict what happens when the message is decrypted.
  4. Two people run the exhibit side by side and choose the same parameter set. Predict which of the values you are about to record will match theirs exactly and which will differ: the artifact sizes in bytes, the hex of the keys and secrets, the verdict sentence at the end of the run.

Do

  1. Open the exhibit. It opens on the Encapsulate / Decapsulate tab. Read What is a KEM? and the diagram beside it, which shows what travels across the wire and what does not.
  2. In the row of parameter-set buttons below that card, press the one you want to run: ML-KEM-512, ML-KEM-768 or ML-KEM-1024. Read the Selected parameter set card and fill in the first table under Record.
  3. Press Next and record the status line printed under the stepper. Press Next again and record it. Press Next a third time and record it.
  4. The run is now finished. In the Artifacts list, record the first eight hex digits shown for Public key, Private key, Ciphertext, Alice secret and Bob secret. Then find the card that has appeared under the stepper showing the two secrets byte by byte, and copy its verdict sentence and the caption printed below that verdict.
  5. Scroll to Full hybrid encryption (ML-KEM + AES-256-GCM) and read its first sentence. Type a short sentence of your own into Message to encrypt, press Encrypt message, and record the status line together with the first eight characters shown for ML-KEM ciphertext.
  6. Press Decrypt message. Record the status line and the line that begins Decrypted plaintext.
  7. Press Tamper with ML-KEM ciphertext. Record the status line and the first eight characters of ML-KEM ciphertext again. Then press Decrypt message a second time and record the status line and the one-line message the page prints directly below it.
  8. Open the Parameter sets tab and read the limits listed under What exactly runs here. Then open the How LWE works tab and, under Jargon, unpacked, expand Fujisaki-Okamoto (FO) transform.

Record

Everything here comes from your own run.

Parameter set I choseNIST categoryPublic key (B)Private key (B)Ciphertext (B)Shared secret (B)
PressWhat the status line said
First Next
Second Next
Third Next
From the finished runWhat the page showed
Public key, first eight hex digits
Private key, first eight hex digits
Ciphertext, first eight hex digits
Alice secret, first eight hex digits
Bob secret, first eight hex digits
Verdict sentence under the two byte rows
Caption below that verdict
Button pressedStatus lineML-KEM ciphertext, first eight charactersOther line the page showed
Encrypt message
Decrypt message
Tamper with ML-KEM ciphertext
Decrypt message, second time

Explain

  1. Your two secret rows hold the same bytes, and the caption you copied says what did and did not travel. Using the diagram on this tab, name what each side held that the other never received, and name the one artifact that crossed the wire. According to the card above the diagram, what does an eavesdropper who copies that artifact still need in order to obtain the secret?
  2. The stepper never asked you for a message; the hybrid card did. Using that card's first sentence and the sizes in your first table, say what ML-KEM established, what encrypted the sentence you typed, and why the page says a KEM on its own does not encrypt data.
  3. In step 7 the page reported a failure only after you pressed Decrypt message, and not at the moment you tampered. Using the Fujisaki-Okamoto (FO) transform entry you expanded, say what the page tells you decapsulation returns when its own check fails, and say which part of the flow — the KEM step or the AES-256-GCM step — produced the message you recorded.
  4. Find the limit about peer authentication under What exactly runs here. Using it, and the KEM card's description of what Encaps takes as its input, say what your run did establish between the two sides and what it did not, and what that limit says a real protocol has to add.

Fix / Extend

  1. Fix. You are reviewing a design that copies this flow as it stands to protect one message to a server, taking the server's ML-KEM public key from a link in an email. Using the limits under What exactly runs here on the Parameter sets tab and the hybrid card's description of the flow, say which of those limits the design trips, what the page says has to be added, and which of three things — establishing a key, encrypting a message, authenticating the other party — the design would still be missing.
  2. Extend. Back on the Encapsulate / Decapsulate tab, press each of the two parameter-set buttons you did not run — ML-KEM-512, ML-KEM-768 or ML-KEM-1024 — and for each one write down the NIST category and the public key, private key, ciphertext and shared-secret sizes from the Selected parameter set card. Then open the Parameter sets tab, read the three profile cards and the card headed Category is a requirement, not a scoreboard, and say which of those numbers grow with the category, which does not, and what the page says should decide the choice.
  3. Extend. Open the Lattice visualizer tab and read the Model boundary card first: it says which part of this exhibit runs the published standard and which parts are small concept models. Then, under Learning With Errors: the noise is the whole point, press Solve A·s = b₀ (clean) and write down the vector the page recovers and the sentence it prints about it; press Solve A·s = b (published noisy) and write down the same two things. Press New random instance and repeat both solves twice more. Using the secret printed above those buttons, say what the noise did to exact elimination, and quote the panel's own sentence on what this does and does not show. If a solve reports that the random matrix was singular, press New random instance and try that solve again.
  4. Extend. Open the vs X25519 / RSA tab. From Fresh key-establishment wire cost, write down the total key material for X25519 ephemeral ECDH, for the parameter set you ran, and for X25519 + ML-KEM-768, and note what the caption underneath says those totals leave out. Then press Run benchmark and write down the median times reported for your parameter set's KeyGen, Encaps and Decaps. Using the note printed under the benchmark, say what the page tells you those numbers do and do not support.

Hybrid Wire

Exhibit
Hybrid Wire live exhibit: https://systemslibrarian.github.io/crypto-lab-hybrid-wire/
Time
About 20 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 5b7ae68ae3bc on 2026-09-22

Predict

Answer these before you open the exhibit. There are no penalties for wrong predictions; the point is to compare them with what you see.

  1. This exhibit derives one session key from two 32-byte secrets: session_key = HKDF-SHA-256(x25519_secret || mlkem_secret). In the exhibit, a wire being "broken" means an attacker has recovered that wire's 32-byte secret, not that the wire stopped carrying bytes. For each of the four rows in the first table under Record — both wires secure, X25519 broken, ML-KEM-768 broken, both broken — predict whether an attacker who is handed the broken wire's real secret, and who must guess anything still hidden, can re-derive the session key and open a record encrypted under it. Write your predictions in that table's prediction column.
  2. Someone says a hybrid handshake is "twice as strong" because it runs two key exchanges. Write down what that phrase would have to mean to be true, and one sentence saying what you would claim instead.
  3. One byte of the ML-KEM ciphertext is flipped in transit to Bob, who then decapsulates it. Predict what Bob ends up with — the same 32-byte post-quantum secret Alice encapsulated, or a different one — and what that does to the session key each side derives. Then predict whether a message Alice encrypted before the flip still decrypts for Bob afterwards.
  4. The attacker in this exhibit gets a small, fixed number of tries: each try runs the real combiner over whatever the broken wires leaked plus a fresh random guess for whatever is still hidden, then tries the intercepted record with the key that comes out. If every try fails, write down what that does show and what it does not show.

Do

  1. Open the exhibit. It opens on the Live handshake tab, and its six phases have already run in your browser — the stepper reveals them one at a time, each with the time it took. Press Next until you reach step 6, reading each phase title as it becomes current. Between step 4 and step 5, watch the Bob shared secret line on the card headed Purple wire — ML-KEM-768 change from pending to bytes: that is Bob decapsulating the ciphertext Alice encapsulated.
  2. At step 6 the outcome cards, the combiner strip and the secure chat appear. Record Total measured handshake time, the heading of the card directly above the combiner strip (leave its icon out of what you write), and the first four hex characters shown under Session key · 32 B. Read the strip left to right first: X25519 secret · 32 B, then ML-KEM secret · 32 B, then the session key.
  3. In the panel headed Secure chat, record the first four characters of Alice fingerprint and of Bob fingerprint, and what Session state reads. Leave the sender menu on Alice, type a short message into the message box, and press the send button beside it. On the message card that appears, press its decrypt button, then record the status pill on that card and what Recipient view shows.
  4. In the same panel's button row, press the control that tampers with the session. Record the status line that appears at the foot of the page, and record Alice fingerprint, Bob fingerprint and Session state again.
  5. Press the decrypt button on that same message card a second time. The message itself has not changed — only the session has. Record the status pill now, the Verification note on the card, and the status line at the foot of the page.
  6. Open the Threat model tab and read the note headed What "broken" means. Leave both switches as they are and fill the first row of the first table: the verdict headline, which of the two input cells reads known to attacker, and the line beneath the verdict that begins Measured this run.
  7. Use the first of the two switches, the one for the X25519 wire, to set that wire to broken, and fill that row the same way. Switch it back to secure, set the ML-KEM-768 wire to broken with the second switch, and fill that row. Finally set both to broken and fill the last row, including the plaintext the page prints for the record it opened.

Record

Every value below comes from your own run.

Wire stateMy predictionVerdict headlineInput cell marked known to attackerMeasured this run
Both wires secure
X25519 broken
ML-KEM-768 broken
Both broken
Handshake outcome at step 6My run
Total measured handshake time
Heading of the card above the combiner strip, without its icon
Session key, first four hex characters
MomentAlice fingerprint, first fourBob fingerprint, first fourSession stateStatus pill on the message
After the handshake, before tampering
After tampering and the second decrypt
LineWhat it said
Status line at the foot of the page, after you tampered
Verification note on the message, after the second decrypt
Status line at the foot of the page, after the second decrypt

Explain

  1. Look at your two single-break rows. In each one the attacker held one wire's real 32-byte secret and ran the same combiner the handshake ran. Using the note printed under the two input cells on the Threat model tab, and the measured line you recorded, explain why the key that came out did not open the record, and say how much of the combiner's input the attacker was still missing.
  2. Your single-break rows report a number of derivations and that none of them opened the record; your both-broken row reports that the record decrypted and the key matched 32 of 32 bytes. Say what the page actually tested in each case. Then say what a run of failed derivations shows about that run, and what it does not show about X25519 or ML-KEM-768 themselves.
  3. The compromised verdict ends with the sentence "Hybrid buys safety against either break alone." Using your four rows, say what that sentence claims and what it does not claim. Compare it with what you wrote for Predict 2: would you now describe this hybrid as twice as strong, and why?
  4. The byte that was flipped was in the ML-KEM ciphertext, and nothing about the message you had already sent changed between your two decrypts. Using your fingerprints and Session state, say which side's session key moved and which did not, and explain why a key derived from both wires changed when one wire's secret did. Your Verification note blames the message's metadata; the status line blames the session keys. Which of the two does your own table support, and what in your record decides it?

Fix / Extend

  1. Fix. An engineer proposes dropping one wire to save the extra handshake bytes: one version keeps X25519 only, the other keeps ML-KEM-768 only. Using your own four rows, say what each version gives up and against which attacker in the table headed Full threat matrix, then state your recommendation in the form the exhibit's own verdicts use. At the foot of the page the exhibit says "Not production crypto — a teaching demo." Say what that note means for how far your recommendation can go.
  2. Fix. Open the Two wires tab and read the HKDF combiner formula, then read the section "A Note on the Combiner" in the demo's README. Say what the combiner's inputs do tie the derived key to and what they do not, name where the README says that missing binding comes from in TLS 1.3, and write out the change the README prescribes for a protocol that has no outer transcript.
  3. Extend. On the Two wires tab, open the aside headed "New to PQ crypto?" and use it to write, in two sentences, why the purple wire sends a packet back and the blue wire does not. Then press the benchmark control on that tab and record the ops/s reported for X25519, for ML-KEM-768 and for the hybrid, and the hybrid's overhead percentage. Compare that percentage with the byte figure the same tab gives for the overhead against pure X25519, and say which of the two a network engineer would care about more.
  4. Extend. Open the Why hybrid tab and read the card headed "Twice as strong?" — No. Write its two-column comparison in your own words. Then name which of your four Record rows is the evidence for the model the card calls right, and say what a row would have had to show for the model it calls wrong to be the better description.
  5. Extend. Back on the Live handshake tab, press Reset, step to 6 again and send nothing. Which values in your second Record table came out the same and which changed? For each, say what part of the handshake fixes it or lets it vary.
  6. Extend. Open the Deployed today tab and pick two cards. For each, write its scheme line and where it says the hybrid is used. Then say which points in the "When to Use It" section of the repository README your two cards illustrate, and which point in that section the cards on the tab do not illustrate.

Harvest Vault

Exhibit
Harvest Vault live exhibit: https://systemslibrarian.github.io/crypto-lab-harvest-vault/
Time
About 21 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 1c8241953291 on 2026-09-22

Predict

This is an extension worksheet: you work it on your own, and nothing here needs an instructor standing over it. Answer these before you open the exhibit. There are no penalties for wrong predictions; the point is to compare them with what you see.

  1. The exhibit keeps a copy of each session you send, as bytes: the panel says the two public keys, the nonce and the ciphertext are copied, that this is what a passive wiretap sees and nothing more, and that your plaintext is never in the copy. After the attack runs, the panel reports for each stored record whether the stored bytes are unchanged since capture. Predict what it will report for a record that was captured before you press Deploy the PQC upgrade, and say why.
  2. You will send one message before deploying the upgrade and one after it. Predict which of the two the attack recovers. For the one you expect it to miss, predict whether the reason is that the attacker failed at the same hard problem it solved for the other message, or something else — and say what that something else would be.
  3. The classical handshake is Diffie-Hellman in a small group, and the attacker searches every candidate private exponent in turn. The panel reports how many exponents it tried and how many were possible. Predict roughly what fraction of the possible exponents the search will get through before it stops, and predict whether two captured sessions will cost the same amount of work.
  4. The calculator on the same page asks whether X + Y > Z, where X is the number of years the data must stay secret, Y is the number of years migration takes and Z is the number of years until Q-Day. Predict whether a profile whose data must stay secret for decades can be moved out of "at risk" by changing Z alone, and say which of the three numbers an organization actually controls.

Do

Work straight down the page. Everything in this section is in two panels.

  1. Open the exhibit. In the step nav that follows you down the page, press 4 · Prove it to reach the panel headed PROVE IT: CAPTURE A HANDSHAKE, THEN UPGRADE. Read the note that begins Toy scale, stated plainly. and keep it in view: the rest of this worksheet leans on it.
  2. In Message to send, replace the text with a short line of your own — something you would not want read aloud. Press Send over the classical handshake and wait for the line under the buttons to say the session was captured. Record the new row's Captured time, its Handshake value, and the start of its Stored bytes cell (the hex run and the SHA-256 that follows it) in the first table.
  3. Press Deploy the PQC upgrade. Read the line under the buttons and record what it says about the records that are already in the store. Notice that the first button has changed its wording.
  4. In Message to send, type a second, different line. Press Send over the hybrid handshake — the same button as before, now relabelled. Record row two in the first table the same way.
  5. Press Run Q-Day and wait until the line under the buttons says Q-Day is complete. For each row, record the At Q-Day cell in the second table: the verdict, the recovered text or the failure line, whether it is byte-identical to what was sent, what it says about the stored bytes since capture, and the exponents-tried figure with its timing.
  6. Read the block headed What this run showed below the table and fill in the third table from it.
  7. Press 5 · Your risk in the step nav to reach the panel headed MOSCA'S THEOREM: X + Y > Z. Without touching the sliders, record the sector name shown as selected, the three slider values, the year printed next to Z, and the verdict line, in the fourth table. Then press the Library sector button and record the same row again.
  8. Scroll to the block headed Across the plausible Q-Day range in the same panel and record its three chips in the fifth table.

Record

Every value in these tables comes from your own run.

SessionCapturedHandshakeStored bytes: hex run and SHA-256
One, sent before the upgrade
Two, sent after the upgrade
SessionVerdictRecovered text, or the failure lineByte-identical to what was sent?Stored bytes since captureExponents tried, and how long
One
Two
What this run showedThe sentence, in your own words, with its numbers
Sessions captured before the upgrade, and how many were recovered
Sessions captured after the upgrade, and how many were recovered
Stored records hashing to what they hashed at capture time
Attacker effort: exponents, time, and out of how many possible
Sector shown as selectedXYZYear next to ZVerdict line as printed
As the page loaded
Library
ChipVerdictThe X+Y and Z comparison as printed
Aggressive
Center
Conservative

Explain

  1. Row one came back as readable text and row two did not. Both messages were protected the same way — the lab's README describes the panel as running HKDF-SHA-256 and AES-256-GCM — and the failure line you recorded for row two names AES-GCM. Using your two rows, say what the attacker had to break in order to read row one, and whether AES-GCM failed there. Then say, for row two, what the attacker did get and what it did not.
  2. Compare the exponents-tried figures in your two rows with each other, and with the "out of" figure in the What this run showed block. Why did the two rows cost different amounts of work, and why will a classmate's figures differ from yours? Using the Toy scale, stated plainly. note, say why this same search would not be the attack at a real Diffie-Hellman size, and what the note says breaks those instead.
  3. Write down the count of stored records that hash to what they hashed at capture time, and the sentence the panel prints after it. Using only that, explain why pressing Deploy the PQC upgrade could not change the outcome for your first message. What would have had to be different about the order of your presses for that message to have survived?
  4. For each of your two rows in the fourth table, write out the X + Y > Z comparison the page printed. Which of the three numbers could an organization in that sector actually change, and which is not theirs to change? Then use your three chips and the page's own note under Across the plausible Q-Day range — "The lesson isn't the exact date — it's whether you survive the whole range" — to say what the page is claiming by showing three Q-Day dates at once rather than one, and what would have to be true of a profile for its three chips to disagree with each other.

Fix / Extend

  1. Fix. Your service runs TLS 1.3 with ECDHE today, and a hybrid key exchange is on the roadmap three years out. Using your two Q-Day rows, write two sentences for a manager: one saying what the upgrade will do for traffic sent after it lands, and one saying what it will not do for traffic sent before. Then name the recorded values you would put in front of them as evidence — and, using the Toy scale, stated plainly. note, say why the exponent count is not one of them.
  2. Fix. The Library profile you recorded printed a verdict at the Z the page had loaded. Using the three numbers in that row, state what would have to change, and by how much, for the same profile to print the other verdict at that same Z. Say which of those levers a library could actually pull, and what the page's context block for that profile — headed LIBRARY PATRON PRIVACY CONTEXT at the foot of the same panel — says about how quickly it could pull it.
  3. Extend. Press 2 · What breaks in the step nav to reach the panel headed WHAT QUANTUM BREAKS — AND WHAT IT DOESN'T. Read both columns, the note underneath them, and the collapsed check below that note. Write down which primitives the page puts in each column, and what it says Grover's algorithm does to AES-256. Then reconcile that with your row one, where a message protected with AES-256-GCM came back in plaintext: name the thing that was broken, and say why the page argues that "we use AES-256" is not an answer to this threat.
  4. Extend. Press 6 · Mitigate to reach the panel headed SECTOR RISK MATRIX + MITIGATIONS. Move focus onto each dot in turn — without activating one, which loads that sector into the calculator — and read what appears in the box below the matrix; write down two sectors that the box puts in different risk states. The legend under the matrix tells you to move the Z slider above to watch dots cross between states. Try that, then try the row of buttons labelled Q-Day assumption: above the matrix, and write down which of the two actually moves the dots — and which sectors change state when it does.
  5. Extend. Back in the calculator panel, set X - Data sensitivity lifetime (years data must remain secret), Y - Migration time (years to complete PQC transition) and Z - Q-Day estimate (years until cryptographically relevant quantum computer) to numbers that match a system you actually use. Read the brief in the box under YOUR RISK BRIEF (Copy brief puts the same text on your clipboard) and write down its verdict line and its "latest year to start" line. The brief prints a name for your sector: compare it with the name on the selector button you pressed, and note any difference between the two.

Crypto Lab exhibits are teaching demonstrations, not production libraries. Do not use exhibit code to protect real data.