Crypto Lab

Hand-out · Key exchange & secure channels

Key exchange & secure channels: 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

DH MITM

Exhibit
DH MITM live exhibit: https://systemslibrarian.github.io/crypto-lab-diffie-hellman-mitm/
Time
About 19 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 8d69dbc7ae4f 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. Eve records everything that crosses the wire: the modulus p, the generator g, Alice's public value A and Bob's public value B. To get the shared secret she has to recover a private exponent. The attack this exhibit runs costs roughly √p steps. Write down roughly how many steps that is for p = 23, and for a 2048-bit modulus, and say which of the two you expect a browser tab to finish.
  2. Mallory can change messages in flight, not just read them. Predict whether she has to solve a discrete logarithm to end up reading Alice's messages. Then say how many secret keys exist once the exchange finishes, and who holds each one.
  3. Take Eve and Mallory separately. For each, predict whether replacing p = 23 with a 2048-bit modulus stops that attacker.
  4. Alice signs her public value with a long-term identity key and Bob checks the signature before he uses the value. Predict what Bob's check does when the value that reaches him is not the value Alice signed, and whether he carries on with the exchange anyway.

Do

The page is one scrollable lesson, not a set of tabs. Each step below names the part it happens in.

  1. Open the exhibit and scroll to Part 2, Eve is watching — and it doesn't help her. Leave Group parameters on Tiny — p = 23, g = 5 and leave Alice secret a and Bob secret b at the values you find. Press Run exchange, then fill the Tiny column of the first table from On the wire (everything Eve sees) and Computed privately (never transmitted).
  2. Press Break it · recover a. Fill the Tiny row of the third table: the exponent the panel says it recovered, the number of group operations, and the milliseconds it reports.
  3. The same panel now prints a cost table. Copy its four rows into the second table, under the headings the page uses: Preset, Size, BSGS cost ≈ √p and Status.
  4. Set Group parameters to Small — p = 2357, g = 2. The panel re-runs the exchange by itself and the exponent boxes refill with that preset's starting values. Press Break it · recover a and fill the Small row of the third table.
  5. Set Group parameters to Realistic — 2048-bit (RFC 3526 group 14). Fill the Realistic column of the first table — for long numbers write down what the panel shows you, including the digit count it prints. Then try to press Break it · recover a, record in the third table whether you can, and read the note in the banner just above the panel.
  6. Scroll to Part 3, Mallory in the middle. Leave Group parameters on Small — p = 2357, g = 2 and leave Alice a, Bob b, Mallory ↔ Alice (m₁) and Mallory ↔ Bob (m₂) at their starting values. Press Run the attack.
  7. Press Next repeatedly, reading each line as it appears, until the step counter beside it reaches the last step; Show all jumps straight there. Fill the fourth table from the three party cards and from the numbered walkthrough lines, then write down the verdict line printed under the two key cards.
  8. Keep or replace the text in Alice's message and Mallory rewrites it to, then press Send through Mallory. Fill the fifth table from the five numbered relay lines and the two cards underneath them.
  9. Scroll to Part 4, Sign the handshake. Press Run signed exchange (honest) and fill the first row of the sixth table from Transcript Bob verifies, Bob's verify() and Bob proceeds?. Then press Run signed exchange (Mallory tampers) and fill the second row the same way, plus the status sentence in your own words.

Record

Everything in these tables comes from your own run.

What the panel showsTinyRealistic
A = gᵃ mod p
B = gᵇ mod p
Alice: Bᵃ mod p
Bob: Aᵇ mod p
The status line under them
PresetSizeBSGS cost ≈ √pStatus
Tiny
Small
Medium
Realistic
PresetCould you press Break it?Exponent the panel says it recoveredGroup operationsMilliseconds
Tiny
Small
Realistic
PartyValue it sendsValue it receivesKey it computes
Alice
Bob
Mallory, facing Alice
Mallory, facing Bob
Relay lineWhat the page showed
What Mallory read
What Mallory forwarded
What Bob receives
Bob reads Alice's original bytes directly?
Signed runThe self value in Transcript Bob verifiesBob's verify()Bob proceeds?
Honest
Mallory tampers

Explain

  1. Compare your group-operation counts for Tiny and Small with the BSGS cost ≈ √p column you copied. The panel says each extra bit of the modulus roughly doubles this attack's work while the exchange itself stays a few multiplications. Does your column agree? Using the Realistic row of the same table, say what running this attack there would cost.
  2. Your first table shows the exchange still finished at production size; your fourth shows Mallory ending the run holding a key with each side, without pressing Break it · recover a at all. Using the page's note about what Mallory did not need, say what she needed instead, and whether running Part 3 on the Realistic group would have stopped her. Then name, for Eve and for Mallory separately, the defence this page offers against each, citing one row of your tables as evidence for each.
  3. The second card in your fifth table asks whether Bob can read Alice's original bytes. Say what failed there and why, using what your fourth table recorded about Alice's key and Bob's key. What does the page say Alice and Bob ended up sharing with each other?
  4. In your sixth table the two runs differ in exactly one field of the transcript Bob verifies. Name that field, and compare the tampered run's value with the value Alice receives in your fourth table. Then use the Unauthenticated DH and Authenticated DH (signed) columns to explain why Mallory cannot simply produce a signature over the transcript she wants Bob to see.

Fix / Extend

  1. Fix. A service you maintain does raw, unauthenticated Diffie–Hellman over a 2048-bit group, and the team proposes moving to a larger group. Using your sixth table and the page's How real protocols authenticate DH list, say what that move does and does not change, name the change the page proposes instead, and say which row of your sixth table the service's handshake would then resemble.
  2. Extend. In Part 3, set Alice a and Bob b to the same number, and Mallory ↔ Alice (m₁) and Mallory ↔ Bob (m₂) to the same number as each other. Press Run the attack, then Send through Mallory again. Record the verdict line and the second card. The page attributes this outcome to the toy modulus; look at the four exponents you typed and at step 5 and step 6 of the walkthrough, and say what else about them explains it.
  3. Extend. In Part 2, put your own number into Alice secret a. Before pressing anything, read the notice that appears at the top of the panel and write down which control it tells you to press. Then press Break it · recover a and compare your group-operation count with a classmate who typed a different number on the same preset. Which of the two numbers in your second table's row for that preset changed, and which did not? Say what that tells you about whether the cost column describes one particular search or the size of the space being searched.
  4. Extend. In Part 2, set Group parameters to Medium — p = 1000003, g = 2. The panel re-runs the exchange by itself and the exponent boxes refill with that preset's starting values. Press Break it · recover a and write down three things: the exponent the panel says it recovered, the number of group operations, and the milliseconds it reports. Put that operation count beside the BSGS cost ≈ √p figure in the Medium row of your second table, and say whether the step up from Small to Medium moves the way that column predicts.
  5. Extend. In Part 2, set Group parameters to Tiny — p = 23, g = 5 and press Break it · recover a. Under the cost table the panel prints two paragraphs: the first warns against generalising that curve to real Diffie–Hellman and names a different algorithm for finite-field groups, the second is about many servers sharing one prime. From those two paragraphs: what sets the security level of the Realistic group, why does the page put that group at about 112 bits rather than at the exponent in its own cost table — the Realistic row of your second table — and what does the page say goes wrong when many servers share one prime?

TLS Handshake

Exhibit
TLS Handshake live exhibit: https://systemslibrarian.github.io/crypto-lab-tls-handshake/
Time
About 24 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit dbbdc73da172 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 handshake signature, and a handshake MAC, are computed over a hash of the messages exchanged so far. Can that hash include the message that carries the signature itself? Say why, and then predict which run of messages the CertificateVerify signature is computed over.
  2. Suppose one bit of the client's X25519 output is flipped, so the two sides run the key schedule from different secrets, and nothing else about the conversation is touched. Predict pass or fail for each of the four checks the exhibit reports: ECDHE outputs agree, CertificateVerify verifies over the transcript the client hashed, client accepts the server Finished MAC, server accepts the client Finished MAC. Write your predictions into the second table under Record.
  3. Now suppose instead that an attacker alters one byte of EncryptedExtensions between server and client, and both sides still compute the same X25519 secret. Predict the same four checks again, in the same table. Then compare your two predictions and say which checks you expect to behave differently between them, and why.
  4. An attacker sitting between client and server has three moves: replay the genuine certificate it copied off the wire and sign with a key it controls; mint its own root and leaf and sign correctly with that; or forward everything unchanged. For each move, predict whether the client accepts the handshake and whether the attacker ends up holding the session secret. Write these into the third table.

Do

  1. Open the exhibit and go to section 2, Interactive Handshake Simulator. Before pressing anything, read the step counter beside Back and Step, and note how many steps the walkthrough has.
  2. Fill the first row of the first table from the detail card beside the ladder: the message name and the encryption badge in its heading, and the byte count on the Flight line under it. Then, under Transcript so far, record the run of messages named in the SHA-256(...) label and the first four characters of the hash beside it. Mark the last column if the page adds a line saying that this exact hash is what gets signed or MAC'd here.
  3. Press Step and repeat for each remaining step, until the counter reaches the last one.
  4. Without pressing any fault button yet, fill the whole Honest session column of the second table. The four verdicts are in the Break this handshake panel at the foot of section 2; the byte-match row is in section 3, Key Exchange — X25519 (EC)DHE, where the two cards each show a 32-byte secret with the bytes marked where the two agree; the chain row is in section 4, Authentication — Certificates & Signatures, and its four verdicts are read once, here, in this column only.
  5. In Break this handshake, press Break the ECDHE agreement. Fill that column of the second table, including the line the panel prints naming what the injection did, and the sentence printed below the four verdicts.
  6. Press Flip a byte in flight and fill the last column the same way.
  7. Press Honest session to return the session to an unfaulted run.
  8. In section 4, press Reuse the server's certificate. Fill that column of the third table from the result box that appears: its headline, the five checks it lists, whether the two transcript hashes it compares are called different or identical, what it says about forwarding the server's own CertificateVerify, and whether the certificate line above them calls the presented leaf the genuine server leaf.
  9. Press Sign with its own key, then Relay unchanged, filling their columns the same way.

Record

Everything here comes from your own run. In the second and third tables, write your prediction in each cell first, then the value you saw beside it.

StepMessage nameBytes on the wireEncryption badgeRun of messages the chip namesFirst 4 hex of that hashCalled out as signed or MAC'd here?
1
2
3
4
5
6
7
8
What the page reportsHonest sessionBreak the ECDHE agreementFlip a byte in flight
ECDHE outputs agree
CertificateVerify verifies over the transcript the client hashed
client accepts the server Finished MAC
server accepts the client Finished MAC
Section 3: any byte marked as differing between the two secrets
Section 4, honest session only: root matches trust anchor, root self-signature valid, leaf signed by root, CertificateVerify signature valid
The line naming what the injection did
The sentence below the four verdicts, in your own words
What the attacker panel reportsReuse the server's certificateSign with its own keyRelay unchanged
Headline: blocked, or succeeded
client completed ECDHE with the peer it saw
presented chain validates under the client's trust anchor
CertificateVerify verifies under the presented leaf key
client accepts the handshake
attacker ends up holding the session secret
The two transcript hashes: different, or identical
Forwarding the server's own CertificateVerify
Is the presented leaf called the genuine server leaf?

Explain

  1. Two pairs of steps in your first table name the same run of messages and show the same hash. Name both pairs. Then, for the pair that includes CertificateVerify, use your answer to Predict 1 to explain why the signature is computed over the transcript that ends just before the message carrying it.
  2. Compare your two fault columns. In one of them the CertificateVerify check held; in the other it did not. Say which column is which, then use what each check is computed over to explain both results, and name the check that caught the broken key agreement.
  3. One of your two fault columns reports that the two sides still agreed on their X25519 secret, and that the CertificateVerify check failed anyway. Say which column that is, and use what the transcript hash covers to explain how one altered byte reached the signature check and both Finished MACs at once, while leaving the panel's remaining verdict, ECDHE outputs agree, untouched.
  4. Which attacker move did the client accept? The panel's headline for that move still does not report a successful attack — say what the attacker ends up holding there, what it would have to change to hold more, and which rows of your third table would start to change if it did.

Fix / Extend

  1. Fix. A client is being written that validates the certificate chain and then treats "the chain validated" as "this handshake is safe". Using your Reuse the server's certificate column, say what that client would accept and what the attacker would be holding, and name the check it left out.
  2. Fix. A second client checks the chain and the CertificateVerify signature but skips both Finished MACs. Using your second table, say which of the two faults it would still refuse and which it would accept, and describe what the two ends would be left holding in the case it accepts.
  3. Extend. In section 5, open Show one derivation in full — how server_handshake_traffic_secret is computed. Record the parent secret it takes, the label it uses, and what its context value is a hash of. Say which of those three would read the same on a classmate's screen and which would not, and why.
  4. Extend. Section 8, Scope — What This Demo Does and Does Not Model, states that the application-data record is the one that is actually AEAD-sealed here, and that messages badged with a handshake key are framed and computed for real but not separately encrypted. Using the badge column of your first table, say which rows that statement applies to, and what the badge is describing if it is not an encryption step this page performed.
  5. Extend. Section 8 also states that chain validation here is three things: the root matches the trust anchor, the root self-signature verifies, and the leaf is signed by the root. Those are the first three of the four verdicts in your second table's section 4 row. List three checks the panel says a real client performs that are absent from this model, and say what a reader of your tables should therefore not conclude from those three verdicts passing.
  6. Extend. Your second table records section 4's chain verdicts for the honest session only; take them back under each fault. In Break this handshake, press Honest session and read the four verdicts in section 4, Authentication — Certificates & Signatures — root matches trust anchor, root self-signature valid, leaf signed by root, CertificateVerify signature valid. Press Break the ECDHE agreement and read all four again, then Flip a byte in flight and read them a third time. Write down which verdicts changed under each fault and which did not, then say what the unchanged ones are computed over that neither injection touched, and which of the two faults reaches the signature check at all.
  7. Extend. Two of the three attacker moves in section 4 are refused, and by different checks. Press Reuse the server's certificate, then Sign with its own key, and for each read the five checks in the result box together with the certificate line above them, which says whether the presented leaf is the genuine server leaf. Name the check that stopped each move, say what each of those checks binds the session to, and use that certificate line to explain why the two moves fail in different places.
  8. Extend. With Honest session selected in Break this handshake, and before pressing anything else, write down the first four hex characters of five values: the leaf Ed25519 public key in section 4, the Early Secret and the Handshake Secret in section 5, the client-computed shared secret in section 3, and the ciphertext and GCM tag in section 6. Then press New session, which re-runs the handshake with fresh keys and returns the walkthrough to the first step, and read the same five again. Mark which of them changed. Two read the same afterwards, for two different reasons: give both, using what section 5 says about the Early Secret and what section 4 says about the leaf key.

Downgrade Wire

Exhibit
Downgrade Wire live exhibit: https://systemslibrarian.github.io/crypto-lab-downgrade-wire/
Time
About 21 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 2de65778ff73 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 client offers two key-exchange groups, a post-quantum hybrid first and a classical one second, and the server supports both. An attacker sitting on the wire deletes the hybrid entry from the client's list before the server reads it. Predict which group the server selects, and whether either endpoint has any way to notice the deletion at that moment. Write your prediction in the first table under Record.
  2. Now suppose the handshake ends with each side computing a MAC over a hash of every handshake message it saw, and each side checking the other's. Predict, for the same deletion, whether the two MACs agree and what the connection does as a result. Write that prediction in the first table too.
  3. The list entry for a group is two bytes on the wire. Predict whether deleting one entry changes two bytes of the handshake or many more, and say what else you think a client has to send for a group it is offering.
  4. Two server settings: one takes the best group that survives the trip, the other refuses to finish a handshake without a post-quantum group. Two client reactions to a failed handshake: give up, or retry with a smaller offer. Predict which combinations still leave an on-path attacker with a downgrade it can use.

Do

This exhibit is one long page of panels, not tabs. Scroll to the panel each step names.

  1. Open the exhibit and read the panel What is negotiation stripping?. Note the one question it says decides whether a strip works.
  2. Scroll to Break it yourself: strip the offer. Under Client → ClientHello read the two rows of supported_groups (preference order): each row shows a group name, its codepoint and whether it is post-quantum or classical. Write both rows into the second table under Record.
  3. Press Play the downgrade. When the results appear, record the line under Server, the Cryptographic result, the Security verdict, the session-key line, and the sentence printed just below the two indicators. These five go in the third table, one row per run.
  4. Look at the Transcript binding control: it now shows Unbound (pre-TLS-1.3 model) selected, and the hybrid row has gone from the client's list. Press Reset offer to put the row back. Confirm Server policy is on PQC preferred, then select TLS 1.3 (transcript-bound).
  5. Press the strip button on the hybrid row, labelled Strip X25519MLKEM768 from the ClientHello, and watch the On-path attacker lane. Press Run handshake and record the same five things as in step 3.
  6. Expand Show the Finished MAC — compute both sides and compare. Record, in the fourth table: the two byte counts in the deletion sentence, the hex on the two 1 · supported_groups on the wire rows, the badge under 2 · Transcript-Hash, and the badge under 3 · server Finished (verify_data).
  7. Press Reset offer, then press Run handshake again with nothing stripped and TLS 1.3 (transcript-bound) still selected. Record the five things from step 3, then expand the Finished MAC panel again and fill in the second row of the fourth table.
  8. Press Compare unbound vs TLS 1.3 and record both cards in the fifth table. Scroll to One config line: PQC preferred vs required, press Run the same strip under both policies, and record both cards in the sixth table.
  9. Scroll to Downgrade by denial of service. Leave Retry without PQ (fail-open) selected under On handshake failure and press Run two rounds; record both attempts and the line below them in the last table. Then select Give up (fail-closed), press Run two rounds again, and record.

Record

Everything below comes from your own run.

QuestionMy predictionWhat happened
Predict 1 — which group, and does anyone notice?
Predict 2 — do the MACs agree, and what does the connection do?
ClientHello rowGroup nameCodepointPost-quantum or classical
First
Second
RunServer lineCryptographic resultSecurity verdictSession-key lineThe sentence below, in your own words
Play the downgrade
Hybrid stripped, TLS 1.3
Nothing stripped, TLS 1.3
Finished MAC panelBytes deleted, and bytes of key_sharesupported_groups the client sentsupported_groups the server receivedTranscript-Hash badgeserver Finished badge
Hybrid stripped, TLS 1.3
Nothing stripped, TLS 1.3
Compare cardCryptographic resultSecurity verdictWhat its note says, in your own words
Unbound (pre-TLS-1.3)
TLS 1.3 (transcript-bound)
Policy cardCryptographic resultSecurity verdictWhat its note says, in your own words
PQC preferred
PQC required
Retry policyAttempt 1: label, offer, resultAttempt 2: label, offer, resultThe line below the attempts
Retry without PQ (fail-open)
Give up (fail-closed)

Explain

  1. Three of your rows in the third table differ in only two things: whether the hybrid group survived to the server, and which Transcript binding setting was selected. Using the page's two indicator names — Cryptographic result and Security verdict — explain why the run that completed is the one the page calls an alarm, and why the run that aborted is the one it calls a defense.
  2. Compare your two rows in the fourth table. In one, the page said the attacker deleted nothing; in the other it reported a deletion much larger than the two bytes of a codepoint. Using the deletion sentence, say what else the attacker had to delete. Then read the note printed under the third stage and state the reason the page gives for the two MACs disagreeing — does that reason turn on how many bytes were deleted?
  3. Walk the three stages the Finished MAC panel prints — 1 · supported_groups on the wire, 2 · Transcript-Hash, 3 · server Finished (verify_data) — and say what changed at each stage in your stripped run and what carried the change from each stage to the next. Then find the Simplified: paragraph in What is real, and what this does not prove: where does it say a real TLS 1.3 stack usually notices the mismatch instead, and does that change whether the strip succeeds?
  4. Both cards in the policy panel ran the same strip with transcript binding off. Say what each policy did with the weaker suite, and, using the paragraph printed below the two cards, name the cost the page attaches to PQC required.
  5. In your fail-open run, attempt 2 completed and the note says every byte of it was validly bound. Explain why transcript binding did not stop that downgrade, and what the attacker had to be able to do for the retry path to work. Then compare your fail-closed run: what did the attacker come away with, and what did the client pay for that?

Fix / Extend

  1. Fix. A client team ships a stack that is "PQC preferred" on the server and retries without PQ when a handshake fails. Using your policy table and your fail-open table, say which of the two settings you would change first and why, and state what the page says each change costs. Say also which of the two settings transcript binding already protects them against, and which it does not.
  2. Extend. Press Reset offer, leave TLS 1.3 (transcript-bound) selected, and this time press the strip button on the classical row, labelled Strip x25519 from the ClientHello. Press Run handshake, expand the Finished MAC panel and record which group the deletion sentence names and how many bytes it reports. Compare that byte count with the one from your hybrid strip and explain the difference, using what the client sends for each group.
  3. Extend. Press Reset offer, set Server policy to PQC required, strip the hybrid row again, keep TLS 1.3 (transcript-bound) and press Run handshake. Record the Cryptographic result and the Security verdict, and compare them with the PQC required card in the policy panel. The two runs differ in one setting; say which check the page reports as the one that stopped the handshake in each, and what that tells you about the order the two checks run in.
  4. Extend. Scroll to The weaker cousin: the downgrade sentinel. With both boxes ticked, record the line the panel prints. Untick Client checks the sentinel and record it again; re-tick that box, untick Server writes the sentinel, and record it a third time. Using the list under Why it is weaker than transcript binding, say which of the three reasons your two unticked runs demonstrated, and which one this panel cannot show you.

Protocol Checker

Exhibit
Protocol Checker live exhibit: https://systemslibrarian.github.io/crypto-lab-protocol-checker/
Time
About 19 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 24c7e9c2dd01 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. The attacker in this model owns the network: it intercepts messages and sends anything it can assemble from what it has seen, but it cannot guess a nonce and cannot open a ciphertext addressed to someone else. Honest A starts a Needham-Schroeder session with a party M that she has chosen to talk to, while honest B runs as responder. Predict whether M can end up holding Nb, the nonce B generated for a session B believes is with A. Say what you think M would have to do with the messages it intercepts.
  2. Lowe's 1995 repair changes one field: message 2 goes from {Na, Nb}_pkA to {Na, Nb, B}_pkA. Predict which party's check fails first when the same relay is tried against the repaired protocol, and which field it fails on.
  3. Now a raw Diffie-Hellman exchange: A and B send public shares with nothing binding a share to its sender, and A then sends a secret under the key she derives. Predict whether an attacker who never recovers anyone's exponent can read that secret, and what it would have to send in place of B's share. Then predict what changes when each share is signed by its sender.
  4. The checker shows two indicators side by side, one labelled Cryptographic primitive and one labelled Security verdict. Predict what each of them reads after a run that finds an attack. Then predict whether the numbers in the status line will be the same for you and for a classmate running the same protocol.

Do

  1. Open the exhibit and go to the Run the search section. Before pressing anything, read the Protocol picker, the three numbered protocol messages below it, and the scenario-and-goal line under those. Write down the term the page names after "does the attacker learn", and which of the three message lines carries the tag this message. Read both indicators and fill the "before any run" column of the first table.
  2. Open the disclosure How the search actually works (for the curious). Read the paragraph listing what the attacker can do with what it holds, and the paragraph after it on the order the search explores in. Note the one rule the page calls the subtle one, and what that rule lets the attacker pass along.
  3. Press Run search. Fill the second column of the first table, then read the status line and fill the Needham-Schroeder Public Key row of the second table.
  4. Find the Attack trace panel and note how many messages the counter under the trace says the trace holds.
  5. Under the trace, step back one message at a time until that counter reads start. In the Attacker's knowledge panel beside it, record the terms the attacker holds before any message and the rule shown on each, in the start row of the third table.
  6. Step forward one message at a time. At each stop, record what the counter reads, the wire line the trace marks as current, the terms the knowledge panel highlights as new, and the rule shown on each of them. Stop when stepping forward no longer advances the counter.
  7. Read the One attacker, two conversations panel and the sentence under it. Fill the Needham-Schroeder Public Key column of the fourth table.
  8. Tick Message 2 includes the responder's identity B. Before pressing anything, note what happened to the verdict, the trace and the status line, and which message line now carries the tag this message. Then press Run search and fill the Needham-Schroeder-Lowe rows of the second and fifth tables, reading the fifth from the panel headed The engine shows its work.

Record

Everything here comes from your own run.

IndicatorBefore any runAfter the Needham-Schroeder Public Key run
Cryptographic primitive
Security verdict
Protocol under testVerdictStates exploredInjections weighedDepthBound
Needham-Schroeder Public Key
Needham-Schroeder-Lowe
Stepper readsWire line marked currentTerms new at this stepRule shown on each
start
message 1
message 2
message 3
message 4
message 5
What the diagram showedNeedham-Schroeder Public Key
Lane marked as deceived
What that lane believes
Who it is actually talking to
Lane with no belief shown
Last wire line of the trace
Re-run after the fixHow the status line ends, in my own wordsWhat the repair panel names
Needham-Schroeder-Lowe

Explain

  1. The Cryptographic primitive indicator read the same thing before and after an attack was found. Using the note under that indicator and the panel at the top of the page, explain what the page is separating by carrying two indicators, and what a reader would lose if the page carried one.
  2. From your third table: at which step did the goal term first appear, and what rule was shown on it? That rule takes two inputs. Name both of them from your own tables — one is a message in the trace, the other is a term the attacker held from the start — and explain why the page can call this a leak of protocol logic rather than a recovered key.
  3. Compare the wire lines of messages 1 and 2, then of messages 3 and 4. One pair shares a body but changes recipient; the other pair is the same line twice. Using the rule list in the disclosure you read in step 2, say what the attacker did to produce each of those two messages, and which of the two needed it to open the message first. Two of your rows in the third table have nothing new in them: say which, what those messages have in common, and why the attack still needs them.
  4. After the fix, the repair panel names a field the pattern requires and a different field the reply carries. Using those two, explain why the relay in your trace no longer reaches its recipient. The panel's last step makes a second claim, about a term the attacker cannot build for itself: state it in your own words and say why the first claim alone would not be enough.

Fix / Extend

  1. Fix. You are reviewing a handshake in which the reply to a challenge returns the challenge but does not name who is sending it. Using the two fields your repair panel named, state the change you would ask for and what a reviewer should be able to check once it lands. Then, using the honesty note at the top of the page and the bound in your second table, say what a No attack in bound result would and would not entitle that reviewer to claim.
  2. Extend. In Protocol, choose Diffie-Hellman key exchange — unauthenticated · signed. Changing the protocol clears the fix and the verdict, so press Run search on a clean page. Write down, in the columns your second table uses, the verdict for Naive Diffie-Hellman together with its states explored, injections weighed, depth and bound. Then read the One attacker, two conversations panel and the sentence under it, and write down which lane is marked as deceived, what that lane believes, who it is actually talking to, which lane has no belief shown, and the last wire line of the trace. Compare all of it with your third prediction.
  3. Extend. With Diffie-Hellman still selected, tick Sign each Diffie-Hellman share and press Run search again. Write down the verdict for Signed Diffie-Hellman and the same four numbers. Then, from the repair panel headed The engine shows its work, write down how the status line ends in your own words and what that panel names.
  4. Extend. Naive Diffie-Hellman gave up its secret and Signed Diffie-Hellman did not, and the obstacle the repair panel names is a signature. Using what you wrote down for those two runs and the last wire line you noted, say what the signature binds and which threat it therefore addresses. Then, using the page's own note on perfect cryptography, name a way of attacking a Diffie-Hellman exchange that this checker's verdict says nothing about, and explain why its model cannot express it. Finally: in the naive run, one lane of One attacker, two conversations is marked as not having run. Using what How the search actually works (for the curious) says about the order the search explores in, explain why the attack did not need that party.
  5. Extend. Compare your second table with a classmate's, row for row. Say which numbers matched and which did not. Then find each of the four protocols in the Each protocol, its goal, its verdict section and check the chip on its card against the verdict you recorded for it — in your second table for the two Needham-Schroeder protocols, and in the two Diffie-Hellman items above for the other two. Explain both results from the way the page describes how its search works.
  6. Extend. In Protocol, choose Kerberos (toy exchange) — ticket handshake. Note what happens to Run search, what the checker shows in place of the schema and the indicators, and the reason the page gives for that entry being a link. Say why a checker that cannot search an entry is better off saying so than showing a verdict for it.

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