Crypto Lab

Hand-out · Security & symmetric encryption

Security & symmetric encryption: 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

Hidden Bit

Exhibit
Hidden Bit live exhibit: https://systemslibrarian.github.io/crypto-lab-hidden-bit/
Time
About 15 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 00705ccbf695 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 game a challenger samples a hidden bit (the coin) and uses it to pick which of two equal-length messages to encrypt; an adversary then tries to name the coin. How often would a blind guess be right? The page scores an adversary with 2 · wins / trials - 1. Predict the score of a blind guesser, and of an adversary that is never wrong.
  2. Suppose one key encrypts the same message twice. Predict whether the two ciphertexts will be identical under AES-ECB, and under AES-GCM, which the page describes as using "a fresh 96-bit nonce".
  3. The adversary Re-encrypt and compare sees both messages, the challenge ciphertext and a public encryption oracle that encrypts messages of its choosing. Fill in the prediction column of the second table under Record: for each row, will that adversary beat a blind guess ("edge") or not ("no edge")?
  4. The page describes AES-CBC, chained IV as CBC "whose next IV is the previous ciphertext tail". If a blind guess and Re-encrypt and compare both show no edge against it, would you conclude that it hides which message was encrypted? What could a third adversary, the BEAST-style IV predictor, do with an IV it can see coming?

Do

  1. Open the exhibit and stay on the Hidden-bit game tab. The page generates an RSA key before its controls appear, so allow a moment. This worksheet uses only the AES choices in Scheme.
  2. In Scheme, choose AES-ECB (BROKEN) and read the hint under the menu. Set Adversary to Random guess. Press Step one four times. After each press, record the coin shown under Seal the coin and the last eight hex characters of the Ciphertext begins line, just before the dots. If all four coins match, keep pressing until the coin changes and record that press as the fourth.
  3. Choose AES-GCM in Scheme, read its hint, and repeat step 2 in the AES-GCM columns.
  4. Leave Trials at 200. For each of the first four rows of the second table, choose that Scheme and Adversary, press Run, and wait until the note under the controls begins "Fresh result". Record Wins, MEASURED ADVANTAGE, the Wilson 95% interval and the first words of the verdict under the advantage bar.
  5. Choose AES-CBC, chained IV (BROKEN). A panel headed A flat line is not a verdict appears below the ledger. Run and record the Random guess and Re-encrypt and compare rows the same way, then record that panel's heading as it now reads.
  6. Open Adversary again: with this scheme it also lists BEAST-style IV predictor. Choose it, press Run, and record the last row.

Record

Values in every table come from your own run.

Step one pressAES-ECB coinAES-ECB ciphertext, last eight hexAES-GCM coinAES-GCM ciphertext, last eight hex
First
Second
Third
Fourth
SchemeAdversaryMy predictionWinsMeasured advantageWilson 95% intervalVerdict, first words
AES-GCMRe-encrypt and compare
AES-CTRRe-encrypt and compare
AES-ECB (BROKEN)Random guess
AES-ECB (BROKEN)Re-encrypt and compare
AES-CBC, chained IV (BROKEN)Random guess
AES-CBC, chained IV (BROKEN)Re-encrypt and compare
AES-CBC, chained IV (BROKEN)BEAST-style IV predictor
Chained-IV panelHeading as it reads
After the Random guess and Re-encrypt and compare runs

Explain

  1. Compare the two halves of your first table. Under AES-ECB, what did presses with the same coin have in common, and was that also true under AES-GCM? The lab's README lists "Deterministic encryption leaks equality" under What Can Go Wrong. Explain that sentence using your AES-ECB records.
  2. Re-encrypt and compare sees both messages, the challenge ciphertext and the public encryption oracle. Describe how a strategy with that name could identify the coin against AES-ECB, then explain why your AES-GCM and AES-CTR rows came out as they did. Use the hint the page shows under Scheme for each.
  3. The same README says: "Chaining the previous ciphertext tail into the next IV gives the BEAST-style adversary a chosen-plaintext equality test." Using CBC encryption as you learned it in class, explain how an adversary that knows the IV its next oracle query will use can choose that query's message so the answer tests which message the challenge contains. Which part of the two ciphertexts would it compare?
  4. Look at your three chained-IV rows and the panel heading you recorded. Using the panel's own sentence and the verdict text under the advantage bar, say what a measured advantage near zero tells you about a scheme and what it does not.

Fix / Extend

  1. Fix. One service encrypts short records with AES-ECB; another encrypts a stream of messages with AES-CBC, taking each IV from the end of the previous ciphertext. For each, name the adversary in your table that did best against it, say what the scheme would have to change so that repeating a message, or knowing the next IV, no longer helps that adversary, and say which of the page's AES schemes you would test in its place. Word your conclusion so it claims no more than the verdict that scheme earned in your run.
  2. Extend. Choose AES-GCM and Random guess. Set Trials to 10 and press Run, then set it to 2000 and run again, recording the Wilson 95% interval each time. How does the interval's width change? Use that to explain why the page refuses fewer than ten trials for Run and says that "a sample is not a proof".
  3. Extend. Compare your second table with a classmate's. Which rows match exactly and which differ? Using the README's note that "Finite samples fluctuate", explain why.

OTP Vault

Exhibit
OTP Vault live exhibit: https://systemslibrarian.github.io/crypto-lab-otp-vault/
Time
About 19 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 6b2bb1c14f73 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. An attacker holds one 14-byte one-time-pad ciphertext and nothing else. You pick any 14-byte message. Predict whether some key turns that ciphertext into your message: for every message you could pick, for only some, or only for the message that was really sent. What would your answer mean for what the attacker can learn?
  2. Two messages are encrypted with the same key: C1 = P1 ⊕ K and C2 = P2 ⊕ K. Write C1 ⊕ C2 and simplify it. Do the same when the second message has its own key, C2 = P2 ⊕ K₂. Which of your two results still contains a key?
  3. One key is reused for both messages. A new random key is drawn and both messages are encrypted again with it. Predict which of C1, C2 and C1 ⊕ C2 will change. Then predict the same when each message has its own key and both keys are redrawn.
  4. You guess that P1 contains the word "the " and slide that guess along C1 ⊕ C2, XORing it with the bytes underneath at each position. Predict what you will see where the guess is in the right place, and where it is not. How will you tell the two apart?

Do

  1. Open the exhibit and scroll to panel 2 · Perfect secrecy — every plaintext is possible. Replace the text in Target plaintext (must be 14 bytes) with a 14-character message of your own, using only unaccented letters, digits and spaces. Record what the page shows. Then type a message of a different length and record what the page says.
  2. Scroll to panel 3 · Two-time pad — the catastrophic key-reuse attack. The key-reuse switch at the top of the panel starts switched on; leave it on and read the status line under the two ciphertexts. This panel shows both messages in Message P1 and Message P2, so you can check every step. Record the first four hex bytes of C1 = P1 ⊕ K and of the combined strip C1 ⊕ C2 (= P1 ⊕ P2 when key reused). Press Re-roll session keys and record which of the two changed, rather than copying the new digits.
  3. Below the strip, the box under Crib (guessed word — try " the ") holds the crib "the ", the menu beside it reads crib is a guess for P1, and the strip's readout says offset 0. Read the line below the controls that says what P2 reads at this offset, then press Pin crib here. Record the pin and the count of bytes recovered under Both plaintexts emerge together.
  4. Type a crib of your own into the crib box: a word or short phrase you expect in either message. Set the menu beside the box to crib is a guess for P2. Move the crib along the strip with the arrow buttons beside the crib box, one byte at a time, or drag the crib marker above the strip. At each offset, read what the other message would say there. When the revealed bytes read as real language, press Pin crib here. If you pin a guess that turns out wrong, press Undo pin and keep moving. When part of a word appears, you can type the whole word you think it belongs to as your next crib.
  5. Turn the key-reuse switch off. Read the new status line, and look at Reconstructed P2 where you pinned the first crib. Record what it shows now. Then record the first four bytes of C1 = P1 ⊕ K and of the combined strip, press Re-roll session keys, and record which of the two changed.
  6. Scroll to panel 4 · Keystream reuse in real ciphers — the same break. Record the first four bytes of C1 = P1 ⊕ S and of the combined strip. Press New (still-reused) keystream and record which of the two changed.

Record

Every value below comes from your own run.

Panel 2 targetText I typedWhat the page showed
Same length as the ciphertext
A different length
MomentFirst four bytes of C1 (hex)First four bytes of C1 ⊕ C2 (hex)Which of the two changed when new key material was drawn
Panel 3, key-reuse switch on
Panel 3, key-reuse switch off
Panel 4, keystream reused
Panel 3 pin (switch on)Crib, exactly as typedGuess for P1 or P2OffsetWhat the other message read thereBytes recovered, as the page counts them
First (the page's own crib)
Second (a crib of your own)
CaseCrib and offsetWhat the other message read thereReads as language?Matches the real message?
Panel 3, switch off: your first pin, as it reads now

Explain

  1. Panel 2 found a key for your own 14-byte message. Using the page's explanation under the target box, say what a single one-time-pad ciphertext tells an attacker and what it does not. Why did the page refuse your other message?
  2. Use the second table. With the switch on, which values changed when you re-rolled the keys, and which stayed the same? With the switch off, what changed? Explain both with the equations in the two status lines you read in panel 3.
  3. One pin filled bytes in both Reconstructed P1 and Reconstructed P2. Starting from C1 ⊕ C2 = P1 ⊕ P2, explain why knowing a stretch of one message gives you the same stretch of the other. What does the page say this means for key reuse?
  4. The page calls an offset where every revealed byte is printable "a plausible hit". How many of the plausible hits you saw were right, and what made you decide an offset was the right one? Then explain why a crib you knew was right revealed nothing readable once you turned the switch off.
  5. Panel 4 says its keystream S is a stand-in, not a ChaCha20 or AES implementation. Using the panel's own description of where a keystream comes from, explain how a repeated nonce leads to the same break as panel 3, and which part of that argument does not depend on how S was made. What did your panel 4 row in the second table show?

Fix / Extend

  1. Fix. One team encrypts every message to a partner with the same one-time pad to save key material. Another encrypts with a stream cipher under one key and a fixed nonce. Using the README's rules for the one-time pad and panel 4's status line, state the rule each team breaks and what each must change.
  2. Fix. Even when every key is used only once, the README names a property the one-time pad does not provide, and what an attacker who knows part of the plaintext can do as a result. Name both, and say what the README recommends instead for general-purpose encryption.
  3. Extend. Open the exhibit at panel 3 · Two-time pad — the catastrophic key-reuse attack and leave the key-reuse switch on. Pin two more cribs of your own, beyond the one you pinned in class: type each into the crib box, move it with the arrow buttons beside the box or by dragging the crib marker above the strip, and press Pin crib here when the revealed bytes read as real language. Set the menu beside the crib box to crib is a guess for P1 for one of them and crib is a guess for P2 for the other. For each, write down the crib exactly as you typed it, which message you guessed it for, the offset the strip's readout gives, what the other message read there, and the count under Both plaintexts emerge together. Then say whether that count rose by the length of each crib, and if it did not, what else it is counting.
  4. Extend. Under Record you wrote only which of the two strips changed when new key material was drawn. Go back and take the digits. In panel 3, with the key-reuse switch on, write the first four bytes of C1 = P1 ⊕ K and of the combined strip C1 ⊕ C2 (= P1 ⊕ P2 when key reused), press Re-roll session keys, and write both again. Repeat with the switch off. Then do the same in panel 4 · Keystream reuse in real ciphers — the same break, using C1 = P1 ⊕ S and pressing New (still-reused) keystream. Compare the before and after digits byte by byte at each of the three moments. Say which comparison comes out identical byte for byte, which does not, and what that tells you about which of the two strips carries key material.
  5. Extend. Open the exhibit at panel 5 · Import two ciphertexts — cryptanalysis playground and press Easy · common words under Or load a challenge:. Read the hint. Both messages are hidden here, so you cannot read a crib off the page first: this is the panel 3 attack without the answer key beside it. Type a crib into this panel's crib box, use the menu beside it to say whether the crib guesses for P1 or P2, and move it with this panel's arrow buttons, watching the offset readout and the bytes the other message would show at each position. Press Pin crib here when they read as language, and pin at least two cribs this way. For each pin write down the crib and its offset, what the other message read there, and whether you judged it real language. Then tick Reveal original P1 & P2 (instructor aid) and add, for each pin, whether it matched the real message. Note also how many offsets the page called a plausible hit before you reached one that was.
  6. Extend. Straight after the Easy challenge, untick Reveal original P1 & P2 (instructor aid) and press Control · NO key reuse. Check that this panel's crib box and offset readout still hold a crib that worked on Easy, and set them again if loading the challenge cleared them. Press Pin crib here, and write down the crib and offset, what the other message reads there, and whether it reads as language. Tick the reveal box again and compare these originals with the ones you revealed on Easy. Then say why a crib that was right a minute earlier recovers nothing here, naming what the two challenges do differently.
  7. Extend. In panel 5, load Medium · military-style and then Hard · unusual vocabulary. Record which cribs each hint suggests and which ones worked. What made the hard challenge harder?
  8. Extend. In panel 3, with the switch on, delete a few words from the end of Message P1 so it is shorter than Message P2. Read the status line that appears, and explain which bytes of the longer message the attack can still reach.

AES Modes

Exhibit
AES Modes live exhibit: https://systemslibrarian.github.io/crypto-lab-aes-modes/
Time
About 14 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit cbfb1b4dfa2c 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 encrypt one 16-character block repeated four times under ECB, CBC, CTR, GCM and CCM, with a fresh random key for each mode. For each mode, predict whether any two ciphertext blocks will be identical. Write your predictions in the first table under Record.
  2. An attacker changes one bit, or one byte, at the start of a ciphertext, and the receiver decrypts it with the correct key. For each of the five modes, predict whether the receiver gets plaintext back and, if so, how much of it changes. Write your predictions in the second table.
  3. A message that decrypts to userdata=guest--;admin=0;------- was encrypted with AES-CBC and nothing else. Could someone who never learns the key make it decrypt with admin=1 instead? Say which part of the ciphertext you think they would change, and what you expect to happen to the rest of the message.

Do

  1. Open the exhibit and choose the Compare tab. In Plaintext, type one block of exactly 16 characters, spaces included, four times in a row with nothing between the copies; the box suggests YELLOW SUBMARINE. Press Encrypt under all 5 modes. For each card, record whether it warns about duplicate blocks and what its note says about integrity or authentication.
  2. Write a test message of at least 40 characters using ordinary letters, digits and spaces, and copy it. You will paste it into each mode's tab so that every mode encrypts the same text.
  3. Open the ECB tab. Paste your test message into Plaintext and press Encrypt with ECB. Note which hex fields the tab fills in, then press Decrypt (after flipping 1 ciphertext block). Record what the page says it changed and what came back.
  4. Open the CBC tab. Paste your test message into Plaintext, press Encrypt with CBC and note the hex fields, then press Demo: Bit-Flip. Record what the page says it changed and compare the original plaintext with the text after the bit flip.
  5. Open the CTR tab. Paste your test message into Plaintext Message 1, press Encrypt with CTR and note the hex fields, then press Decrypt (1-bit ciphertext flip). Record the result.
  6. Open the GCM tab. Paste your test message into Plaintext and leave the other fields as they are. Press Encrypt with GCM and note the hex fields, then press Demo: Tamper Detection. Record what the page reports.
  7. Open the CCM tab. Paste your test message into Plaintext, press Encrypt with CCM and note the hex fields, then press Demo: Tamper Detection. Record what the page reports.

Record

Everything you record comes from your own run. Leave the hex itself out: the tables ask what the page showed and said.

Compare cardMy prediction: any identical blocks?Duplicate warning on the cardWhat the card's note says about integrity or authentication
ECB
CBC
CTR
GCM
CCM
Mode tabHex fields the tab fills inMy prediction for a changed ciphertextWhat the page says it changedWhat came back, or what the page reported
ECB
CBC
CTR
GCM
CCM

Explain

  1. The CBC tab's CBC Vulnerabilities notes say that flipping bit i of ciphertext block n flips bit i of plaintext block n+1. Use that rule to explain your CBC Demo: Bit-Flip result: what happened to plaintext block 0, what happened to plaintext block 1, and why.
  2. Explain the GCM and CCM results you recorded. According to the page, what does each mode check before it releases plaintext, and what does that check cover?
  3. Sort ECB, CBC, CTR, GCM and CCM into "confidentiality only" and "authenticated encryption", citing one entry from your tables for each mode. Did any mode in the first group also leak something in your Compare run, without anyone changing the ciphertext?

Fix / Extend

  1. Fix. You maintain a service that keeps admin=0 inside an AES-CBC ciphertext with no MAC, as in the targeted bit-flip demo in item 4. Using the page's Which mode should I use? list and the threat model on the CBC tab, name two changes the page supports. For each one, say how the CBC row of your second table would read afterwards, and why.
  2. Extend. On the CBC tab, replace your test message with one shorter than 16 characters. Press Encrypt with CBC, then Demo: Bit-Flip, then Decrypt (tampered ciphertext), and record what the page reports each time. Using which block your change landed in, explain why a one-block message behaves differently from your longer one. If the page reports an error, note what it calls that error; the next exhibit in this module builds on it.
  3. Extend. On the Compare tab, change one character in just one copy of your repeated block and press Encrypt under all 5 modes again. Which ECB blocks still match each other? Using the threat model on the ECB tab, say what an attacker who sees only that ciphertext learns about your message.
  4. Extend. On the CBC tab, press Demo: Targeted Bit-Flip (admin=0 → admin=1). This demo encrypts its own fixed message under a new key, so nothing you typed earlier affects it. Write down the three lines the panel shows: the original decrypt, the text after the flip, and the verdict line. The panel also prints the block layout it used and the rule P₁[i] = AES⁻¹(C₁)[i] ⊕ C₀[i]; using both, explain why changing a byte of C₀ changed admin=0 in P₁, and what the same change did to the block before it. This is the scenario you predicted in Predict question 3.
  5. Extend. On the Compare tab, use the run from Do step 1 — four copies of one 16-character block under Encrypt under all 5 modes, retyped and re-encrypted if you have closed the exhibit. Using the duplicate-warning column of your first table, those cards' notes and the tab's What to look for section, explain why repeated 16-character input blocks came out as repeated ciphertext blocks on the cards that warned and not under the other modes.
  6. Extend. The CTR tab describes encryption as XORing the plaintext with a keystream made from counter values. Using that description and the CTR row of your second table, explain the change Decrypt (1-bit ciphertext flip) produced, and how that result compares with the CBC row of the same table.

Padding Oracle

Exhibit
Padding Oracle live exhibit: https://systemslibrarian.github.io/crypto-lab-padding-oracle/
Time
About 24 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit 3a7e02e6daeb 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 receiver decrypts a block that reads 0x10 sixteen times, which is a full block of PKCS#7 padding. An attacker can change only the last decrypted byte. For each value below, predict whether the receiver will still call the padding valid. Write your predictions in the first table under Record.
  2. Suppose a server answers only "padding valid" or "padding invalid" and never shows the decrypted text. Can an attacker who never learns the key still recover the plaintext? Say what you think the attacker would have to change between one question and the next.
  3. Roughly how many questions ("oracle queries") do you expect it to take to recover one 16-byte block: fewer than a hundred, hundreds, a few thousand, or millions? Explain your guess.
  4. Three servers receive the same attack. One reports padding errors, one gives the same response whatever its padding check found, and one checks a MAC before it decrypts anything. Predict which of them will give up the plaintext.

Do

  1. Open the exhibit and stay on the CBC & Padding tab. Read the CBC decryption rule at the top of the tab.
  2. Scroll to Your Turn: Craft the Last Padding Byte and press Set Up Practice Ciphertext.
  3. Choose a value in Force last decrypted byte to, then press Predict: Valid or Predict: Invalid to match your prediction from question 1. Read the oracle's answer and the page's explanation, and record the answer. Repeat for every value in the list.
  4. Open the Full Block tab. Type your own text of about 16 characters into Target plaintext. Set Animation speed to Slow if you want to watch the first bytes recover one at a time.
  5. Press Encrypt Target Block, then Run Full Block. When it finishes, record the result, the byte-for-byte badge and the number of oracle queries used.
  6. Without changing your text, press Encrypt Target Block and Run Full Block again. Record the second run.
  7. Open the Defenses tab. Under Same Attack, Three Servers, leave or change Plaintext to attack, then press Run Attack Against All Three. Record each row of the table.
  8. Under AES-GCM Live Demo: Tampering Rejected, press Encrypt with AES-GCM, then Tamper Ciphertext. Record what the page reports.

Record

Values you record in the second and third tables come from your own run.

Forced last byteMy predictionOracle's answer
0x00
0x01
0x02
0x03
0x0f
0x10
0x41
Full Block runTarget plaintextBadge (match or mismatch)Oracle queries used
First run
Second run
ServerOutcomeOracle queriesPadding checks reachedMAC rejections
Leaky CBC
Silent CBC
Encrypt-then-MAC
AES-GCM tamperWhat the page reported, in your own words
After Tamper Ciphertext

Explain

  1. Which forced values did the oracle accept? Using the rule that the last byte of a block says how many padding bytes there are, explain why those values pass and the others fail.
  2. The attacker never sees the key. Using the decryption rule on the CBC & Padding tab, explain how changing one byte of the previous ciphertext block, and watching only valid or invalid, lets the attacker learn one byte of plaintext.
  3. Your two Full Block runs used the same text. Why did the number of oracle queries change, and why is your count different from a classmate's? What stayed the same?
  4. The silent server still ran a padding check on every query. Why did the attack fail against it, and why does the page call this the fragile defense?
  5. Against Encrypt-then-MAC, the attack's queries never reached the padding check. What stopped them first?

Fix / Extend

  1. Fix. You maintain a service that decrypts AES-CBC messages and returns one error for bad padding and a different one for bad data. Rank the three defenses on the Defenses tab (uniform errors, Encrypt-then-MAC, authenticated encryption) and justify the ranking by what an attacker can still observe under each.
  2. Extend. Open the Hall of Fame tab and pick one real exploit. Identify what played the part of the oracle in that system: an error code, a protocol alert or a timing difference.
  3. Extend. Open the Full Decryption tab, type a message several blocks long into Plaintext to encrypt and decrypt, press Generate Ciphertext, then Run Full Attack. Describe how the query count grows with the number of blocks and compare it with the complexity the tab states.

Nonce Collision

Exhibit
Nonce Collision live exhibit: https://systemslibrarian.github.io/crypto-lab-nonce-collision/
Time
About 15 minutes of class time; Predict is pre-class reading and Explain is a spoken debrief
Checked against
Lab commit d23b6ec02c35 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 key, one nonce, two messages. For each of AES-CTR, AES-GCM, ChaCha20-Poly1305 and AES-CBC (where the nonce is called an IV), predict what an attacker who sees only the ciphertexts, and the tags where there are tags, can gain: the plaintext, the ability to forge a tag, the fact that the two messages begin the same way, or the encryption key. Write your predictions in the first table under Record.
  2. AES-CTR encrypts by XORing the plaintext with a keystream that depends only on the key and the nonce. Predict what C₁ ⊕ C₂ looks like when each message gets its own nonce, and when both share one. If you repeated the shared-nonce case with a brand-new key and a brand-new nonce, would C₁ ⊕ C₂ change?
  3. Suppose nonce reuse lets an attacker recover the secret an AEAD tag is computed with, but not the key used to encrypt. Predict what that attacker can do to a message sent under the reused nonce, and to a message sent under a fresh one.
  4. Two messages begin with the same text and are encrypted with AES-CBC. Predict whether any of their ciphertext blocks will be identical when each gets its own random IV, and when they share one IV.

Do

  1. Open the exhibit and scroll to Same mistake, four outcomes. Read the note on the two indicators: the cryptographic result is what the primitive returned, and the security verdict is whether the guarantee still holds.
  2. On the AES-CTR card, make sure Reuse the nonce is off and press Run. The card encrypts two messages under fresh nonces and prints C₁ ⊕ C₂ as a lane of hex bytes. Record the first four bytes. Press Run again and record the first four bytes again.
  3. On the AES-CBC card, make sure Reuse the IV is off and press Run. Record the number after Shared leading ciphertext blocks. Press Run again and record it again.
  4. Press Run all four — one reused nonce. Every card switches to a reused nonce and runs.
  5. On the AES-GCM card, record the cryptographic result, whether the recovered H matches ground truth, and the first eight hex digits of recovered H. On the ChaCha20-Poly1305 card, record the cryptographic result, whether the one-time key matches ground truth, and the first eight hex digits of recovered r.
  6. On the ChaCha20-Poly1305 card, find the lane of hex bytes labelled C₁ ⊕ C₂ = P₁ ⊕ P₂. Count how many bytes at its start are 00, and note the first byte that is not. On the AES-CTR card, record the as text line: message 2, recovered by XORing message 1 back in. On the AES-CBC card, count the ciphertext block rows marked identical.
  7. Press Run all four — one reused nonce a second time and record the same values again.

Record

Values you record in the second, third and fourth tables come from your own run.

ConstructionMy predictionWhat the card computed, in your own words
AES-CTR
AES-GCM
ChaCha20-Poly1305
AES-CBC
Fresh-nonce runAES-CTR: first four bytes of C₁ ⊕ C₂AES-CBC: shared leading ciphertext blocks
First run
Second run
Reused-nonce runCardCryptographic resultMatches ground truthRecovered value, first eight hex digits
First runAES-GCM
First runChaCha20-Poly1305
Second runAES-GCM
Second runChaCha20-Poly1305
Reused-nonce runAES-CTR: message 2 as recoveredChaCha20-Poly1305: leading 00 bytes, then the first other byteAES-CBC: block rows marked identical
First run
Second run

Explain

  1. Did your recovered H and recovered r change between your two reused runs? The page says H is fixed by the key, and the one-time key (r, s) by the key and the nonce. What does your answer tell you about the key each run used? Now compare how the fresh AES-CTR lane and the reused ChaCha20-Poly1305 lane behaved across two runs (the consequence table lists keystream reuse for both), and explain the difference using C₁ ⊕ C₂ = P₁ ⊕ P₂. What do the 00 bytes at the start of the reused lane say about the two messages at those positions?
  2. The AES-GCM and ChaCha20-Poly1305 verifiers both accepted a tag the attacker computed. Why does the page treat a VALID result here as an alarm rather than a success?
  3. Name the secret each authenticated card recovered and the key the page says it did not recover. Using Why the forgeries work — one cancellation, twice and the consequence table, say what an attacker holding the recovered value can do under the reused nonce, and what the page says it cannot do to a message sent under a fresh nonce.
  4. AES-CTR gave up message 2 but has no tag to forge. Using your AES-CBC block counts, explain what an attacker learns from identical leading CBC blocks and what the card says the attacker does not learn. Why does the page call CBC's failure weaker?

Fix / Extend

  1. Fix. A service encrypts with AES-GCM under one long-lived key. One engineer proposes random 96-bit nonces; another proposes a counter kept on a virtual machine that is sometimes restored from a snapshot. Using Where a nonce actually repeats, explain how each proposal could still repeat a nonce. Using Fixes, and what this lab is not, say which remedy the page offers against each risk, and what the page says AES-GCM-SIV would still leak if a nonce did repeat.
  2. Extend. Under Why the forgeries work — one cancellation, twice, expand the AES-GCM derivation and press Run it on real bytes and cancel. Record whether each check line under the computed values passed. Press the button again (it now reads Run it again with new keys) and compare tag₁ and the recovered H with your first press. Which values changed, and which checks still held?
  3. Extend. Under Random 96-bit nonces and the birthday bound, choose 32-bit and move Messages encrypted (log scale) until the collision probability passes one half. Then choose 96-bit (GCM) and read where the page puts a 50% chance. Compare that with the random-IV limit stated in the note below the readouts, and explain why the limit sits so far below the 50% point.

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