# Digital Trust in a Quantum Era — Starter Module: Teacher Pack **Pilot draft v0.1 • October 2026 • For school review** One starter module within the broader QSFS platform. Three original, offline-first lessons help students reason about cybersecurity as quantum computing develops. Proposed first audience: secondary Years 7–10 in Victoria; teachers adjust depth. A primary adaptation is planned later. These are review-ready teaching resources, not validated program outcomes or an accredited course. They need school curriculum and scientific review before piloting. **Central outcome:** informed student decision-making — explain what cryptography protects, recognise the specific future quantum risk, and justify proportionate responses using evidence. Students do not audit or alter school systems. Fictional cases, paper and discussion only: no accounts, internet, personal records, passwords, hacking or paid technology. **Sequence:** three 60-minute lessons, short assessment before Lesson 1 and after Lesson 3. For 45-minute timetables: move each lesson’s extension to a separate session, reduce reporting groups rather than removing explanation or assessment, and use the supplied results rather than repeated trials. Student materials are in the separate **Student Pack** (no answers). This pack contains answers. --- ## Preparation and safeguarding - Print one student task sheet per pair, cut one set of case cards per group, board and pens ready. - Lesson 2: one coin per pair or the supplied synthetic sequence. Coins stay on desks; offer a no-manipulation alternative. - Read all answer notes; rehearse the circuit example if using it. Record actual preparation time during the pilot. - Use only invented people, messages and services. Do not invite students to disclose passwords, health details, family experiences of fraud or school security weaknesses. Students may pass on personal discussion and use the fictional case. Any disclosure follows the school’s normal safeguarding procedures. No real security testing. Optional external tools require normal school approval; the core works without them. - Oral, written or diagram responses are always permitted. Use numbered labels, not colour alone. Read case cards aloud; pre-teach the glossary; allow pair rehearsal before whole-class talk. Rotate reader, evidence checker, recorder and reporter. Keep all core work in school time. ## Curriculum links for teacher validation Victorian Curriculum F–10 Version 2.0 Digital Technologies offers potential alignment through Level 8 (network security; identifying cybersecurity threats) and Level 10 (evaluating threats/vulnerabilities and how systems secure access to network data). These are achievement-standard links; teachers add exact content-description codes from the current official curriculum. No VCAA endorsement or complete coverage is claimed. Mathematics (later primary adaptation): VC2M5P01 and VC2M5P02 (possible/equally likely outcomes; repeated chance experiments). VC2M8P01 (complementary probabilities) may support Lesson 2. Quantum amplitudes are optional extension only. Sources: [Digital Technologies Version 2.0](https://f10.vcaa.vic.edu.au/learning-areas/technologies/digital-technologies/curriculum) · [Mathematics Version 2.0](https://victoriancurriculum.vcaa.vic.edu.au/mathematics/mathematics-version-2-0/curriculum/f-10?layout=3) --- # Lesson 1 — What are we protecting? **Audience:** Years 7–10, entry lesson. **Length:** 60 minutes. **Prerequisite:** everyday understanding of messages and accounts. **Materials:** student sheet, case cards, board, paper, pens. **Output:** an annotated fictional message journey and a justified protection choice. **Learning intention:** distinguish confidentiality, integrity and authenticity; explain why cryptographic keys matter; identify why one protection does not solve every security problem. **Success criteria:** name the protection needed in two scenarios; describe a public/private-key arrangement without calling the public key a password; explain why encryption alone does not stop a deceptive request. ## Teacher concept note Confidentiality concerns who can read information. Integrity concerns detecting or preventing unauthorised changes. Authenticity concerns confidence about who or what produced information. Availability also matters but is not today’s focus. In symmetric encryption, authorised parties use a shared secret key. Public-key cryptography uses a mathematically related public/private key pair. Depending on the scheme, these support key establishment or digital signatures. A digital signature can help verify origin and detect alteration but does not hide the message; encryption alone does not necessarily establish origin or integrity. Real systems also need trustworthy key distribution, secure devices and correct implementation. ## Sequence - **0–6 Start with a problem.** “A fictional club has sent a meeting time. Someone changes 3 pm to 5 pm. The message was never secret. What failed?” Take two answers without correcting. “A private fictional note is copied but not changed. Is that the same failure?” - **6–14 Name the protection.** Teach the three terms with the two examples. “A message can be public and still need a trustworthy source. A hidden message can still be sent by someone misleading you.” Add availability (inaccessible timetable) as another need, not today’s topic. - **14–25 Sort the case cards.** Groups sort under confidentiality, integrity, authenticity or more than one, explaining the harm. Justified multiple answers accepted. Debrief Cards 2 and 4. - **25–36 Follow a key diagram.** Model A: shared secret key between two trusted endpoints. Model B: public key distributed, private key protected. “For a suitable public-key encryption scheme, someone uses the recipient’s public key to encrypt and the recipient uses their private key to decrypt. Key establishment and signatures have different jobs; they also use public-key methods. Today our diagram is a role model, not an implementation.” Ask: “How do we know this really is the recipient’s public key?” A trusted directory/certificate mechanism is needed; a self-asserted label is not proof. - **36–47 Build the message journey.** Pairs annotate a fictional public club announcement; mark forged source, changed message, leaked private attachment; propose a control for each; mark one problem their control does not solve (e.g. signature verification doesn’t establish every claim is true). - **47–55 Explain the limits.** “Our app encrypts every message, so every request inside it must be safe.” Groups write a correction. “Cryptography can protect a communication channel. It cannot decide whether a person is trustworthy or a request is sensible.” Relate to checking unusual requests through a known route (no site visits). - **55–60 Exit ticket.** ## Answers **Case cards:** 1 confidentiality; 2 integrity; 3 authenticity; 4 confidentiality despite a valid signature; 5 human/contextual decision risk, not proof that encryption failed; 6 availability. Accept multiple well-explained answers. **Task C:** public keys are designed for public use in the relevant scheme; private keys must remain protected; signatures help check origin/integrity but do not hide content or prove every statement true. **Task D:** encryption protects who can read the message; it says nothing about the sender’s honesty. **Exit ticket:** 1. Public timetable secretly changed? **Integrity; authenticity may also matter if the source is impersonated.** 2. Does a digital signature keep a message secret? **No. It supports origin/integrity checks when keys and verification are trustworthy; confidentiality needs encryption.** 3. Why can an encrypted message still be risky? **Deceptive sender, wrong recipient, unsafe request or compromised endpoint.** **Rubric:** 0 = no relevant explanation; 1 = correct label, incomplete reasoning; 2 = correct label and plausible limitation. Per exit response, total 0–6. Local formative rubric, not validated. **Support:** three-term glossary with icons; sentence starters. **Extension:** why a stolen private signing key undermines authenticity; message truth vs verified source. **Primary later:** Cards 1–3 with secrecy/change/source language; defer public-key detail. --- # Lesson 2 — What quantum changes and what it does not **Audience:** Years 7–10; circuit extension optional. **Length:** 60 minutes. **Prerequisite:** Lesson 1 terms; simple fractions and multiplication. **Materials:** evidence cards, board, coin per pair or supplied sequence, paper. **Output:** a corrected quantum-security claim with evidence and a stated limit. **Learning intention:** describe quantum computing as specialised rather than universally faster; interpret a simple measurement model without equating a qubit with a coin; explain why future quantum capabilities matter to some public-key cryptography while everyday precautions remain useful. **Success criteria:** distinguish a difficult mathematical task from an impossible one; recognise one measured qubit gives one classical outcome in the chosen measurement; correct “quantum breaks every password today”. ## Teacher concept note and accuracy boundary A classical bit has value 0 or 1. A qubit has a quantum state. A superposition is described by amplitudes, which determine outcome probabilities and can interfere. In the standard 0/1 measurement one measurement returns one outcome. A coin models a probability distribution, not a quantum state. The card rule system represents predictions for a restricted ideal circuit; it is not experimental proof, a processor or a simulation of every state. Optional rule activity: Hadamard H and states 0, 1, plus, minus (labels, not signs of probability). Ideally H maps 0→plus, plus→0, 1→minus, minus→1. Plus and minus each give 0/1 with equal probability in this basis, but their different phases matter to later operations — outcome probabilities alone do not fully describe a state. Technical basis: [IBM Quantum — single systems](https://quantum.cloud.ibm.com/learning/en/courses/basics-of-quantum-information/single-systems/quantum-information). Security context: [ASD computing primer](https://www.cyber.gov.au/publication/quantum-technology-primer-computing). ## Sequence - **0–7 Retrieve and predict.** Recall one confidentiality example and one signature use. Display: “Quantum computers will soon replace every computer and break every password.” Underline words needing evidence: soon, every, replace. Do not ask for a breakthrough date. - **7–17 Probability without the quantum claim.** Pairs toss a coin 20 times or use the synthetic sequence. Is 10 heads guaranteed? Do random-looking results establish a quantum process? **No and no.** A fair coin is a useful sampling model but does not capture interference. - **Synthetic sequence (authored, not measured):** H, T, H, H, T, T, H, T, H, H, T, H, T, H, T, H, H, T, H, T. **Count: 11 heads, 9 tails. Proportion of heads 11/20 = 0.55.** Not research or quantum hardware results. - **17–32 Investigate a mathematical security idea.** Half the pairs: “Calculate 17 × 19”. Half: “Find two whole numbers greater than 1 whose product is 437”. Two minutes, share methods. **Answers: 323 and 19 × 23.** Is checking a proposed pair easier than searching without one? Does this prove a security claim? It does not. Say: “Some public-key systems rely on mathematical tasks being impractical to solve at their real sizes using known practical methods. Multiplying and finding factors illustrates a direction-of-work idea. These tiny numbers provide no security. Different schemes use different problems. A known quantum algorithm could change the difficulty of factoring large numbers on a sufficiently capable computer, which is one reason traditional public-key systems need preparation.” Do not time or rank pupils. Students annotate: changed computational capability → changed security assumption → need to review the affected system, and the evidence needed at each step. - **32–39 Explain the model limits.** “A quantum computer uses quantum states and operations; it is not just a machine tossing coins faster. A measurement gives an outcome, not a readable list of all possible answers. Quantum algorithms gain advantages for particular tasks through carefully designed operations, including interference. The coin and small-number activity do not demonstrate quantum computing or break a real system.” Groups write what each model helps with and one thing it does not establish. - **39–51 Sort the evidence cards** into current evidence/guidance, future conditional risk, or unsupported conclusion. Each group corrects one unsupported statement in 30 words. PQC is built for ordinary computing systems; it is different from quantum key distribution. - **51–60 Exit explanation.** “A useful action now is … because … . One claim I would challenge is … because … .” ## Evidence card answers 1. ASD 2026: no cryptographically relevant quantum computer yet — **current official statement; review source before reuse.** 2. Future computer could compromise traditional public-key methods — **conditional future risk.** 3. “Quantum-safe” product with no standard, scope or tests — **unsupported assurance; request evidence.** 4. NIST published three principal PQC standards in 2024 — **current documented standardisation, not proof every service has migrated.** 5. “Quantum already breaks every password and encryption” — **unsupported, overbroad.** 6. “Updates and checking unusual requests no longer matter” — **unsupported and unsafe.** ## Optional paper circuit extension (later 15–20 minutes) Not needed for core outcomes. Read the rule card aloud (Student Pack). Predict: A = 0, H, measure; B = 0, H, H, measure; C = 0, H, measure, H, measure. Reveal answers after predictions. Ask why calling H a coin toss fails to predict B. Real devices can depart from ideal predictions through errors. **Answer card:** - **A:** 0 → H → plus → measure. Each run 1/2 for each outcome. Across 100 runs expected 50 and 50; exact split not guaranteed. - **B:** 0 → H → plus → H → 0 → measure. Ideal prediction: 0 every run. Real hardware can deviate through errors. - **C:** 0 → H → plus → measure gives 0 or 1; H then gives plus or minus respectively; final measurement 0 or 1 with equal probability. The intervening measurement changes the final distribution from B. ## Exit questions and answers 1. Why don’t the coin and small-number activities demonstrate quantum codebreaking? **The coin models simple outcome frequencies; the factor task uses tiny unprotected numbers. Neither is a quantum processor or real attack.** (If extension taught, accept interference/H–H distinction.) 2. Does 50% guarantee exactly 50 zeros in 100 trials? **No; expected count, not a guarantee.** 3. Relevant future concern? **A sufficiently powerful quantum computer could defeat certain traditional public-key methods, affecting confidentiality, signatures and/or authentication depending on the system.** 4. Does PQC require buying a quantum computer? **No. PQC runs on conventional computers.** 5. Why continue everyday precautions? **Cryptographic changes don’t remove current risks from compromised accounts, deception or insecure systems.** **Rubric:** 0–2 each (inaccurate / partly / accurate with relevant boundary). Q4: 2 requires correct answer plus conventional-computer explanation. Total 0–10. **Support:** supply the factor pair; discuss checking versus searching. **Extension:** circuit; why plus and minus share probabilities here but differ after H. --- # Lesson 3 — Make a defensible security decision **Audience:** Years 7–10; strongest independent analysis at Years 9–10. **Length:** 60 minutes. **Prerequisite:** Lessons 1–2. **Materials:** scenario and option cards, template, board. **Output:** one-page recommendation with evidence, uncertainty and next step. **Learning intention:** prioritise using data sensitivity, confidentiality lifetime, consequences and evidence; explain why future planning and current protection both matter; know students escalate concerns rather than alter real systems. **Success criteria:** justified priority; two specific evidence questions; rejection of an unsupported “quantum-safe” claim; safe, authorised next step. ## Teacher concept note “Harvest now, decrypt later” describes retaining encrypted data for possible future decryption. Long-lived confidentiality can make future capability relevant today. It does not mean every record is already stolen, that all encryption is equally exposed, or that anyone can give an exact arrival date. Public-key systems also support signatures and authentication; those risks differ from secrecy. All dates and vendor messages in the scenario are invented. ## Sequence - **0–8 Retrieve.** Which Lesson 1 goals apply to A, B, C? Require a main priority. Emphasise B’s long-lived secrecy and A’s integrity/authenticity. - **8–16 Timeline.** Mark today, B’s confidentiality period and a question mark for future capability. Why is no exact date needed to begin planning? “A preparation deadline is a management choice; it is not the predicted date an attack becomes possible.” - **16–31 Choose and justify.** Groups choose three option cards: one near-term issue, one future-risk inquiry, one evidence request. Reject any card with a written reason. No budget numbers. - **31–43 Challenge.** Exchange: “Which fact supports this?”, “What remains unknown?”, “Who is authorised to act?” Improve one recommendation. Reward proportionate uncertainty. - **43–54 Write the decision brief** (template in Student Pack). - **54–60 Exit and debrief.** “Your useful skill is asking good questions and recognising evidence. A school or organisation’s authorised technical team makes system changes.” ## Answer guide Sound choices include **A plus B/D/F, with H as follow-through**; several combinations work if they meet all three purposes. **Reject C, E and G:** C lacks evidence, E ignores present risks, G is outside authority. Vendor 2 is more useful but has not thereby proved secure deployment — ask for product/version/function scope, standards, testing and unresolved components. Vendor 1’s absolute claim is unjustified. Vendor 3 confuses password/account protection with cryptographic transition. Service A: confidentiality is not the main issue for a public timetable; integrity/authenticity matter. Service B: strong planning priority (long confidentiality, stated dependency); exact urgency depends on missing information. Service C: prompt, authorised response to a present concern, without assuming a breach. **Exit answers:** 1. Why can future risk matter to data sent today? **Encrypted material can be retained; long-lived confidentiality may outlast today’s protection.** 2. Is a public timetable free of security concerns? **No: integrity, authenticity and availability.** 3. Why is vendor 2 more useful without proving safety? **Specific, checkable scope/standards/dates and acknowledged limits; claims still need verification.** 4. What should a student do about a real school-system concern? **Use a trusted teacher/school route, avoid sharing details publicly, no unauthorised tests or changes.** **Rubric (0–2 each, max 10):** accurate security goal; relevant evidence; proportionate prioritisation; explicit uncertainty; safe ownership/next step. Matching the teacher’s cards without reasons is insufficient. **Extension:** revise if B no longer uses the affected method, or C is confirmed legitimate. **Support:** two prepared evidence questions to choose and explain. --- # Staff professional learning session (45 minutes) Audience: participating teachers; ICT colleague welcome. Purpose: facilitate accurately and identify support needs. Completion = participation plus teach-back; attendance alone is not certification. - **0–5 Scope.** “This is student cybersecurity literacy using quantum change as a context… We are not training students to alter cryptography.” Name one likely teaching barrier. - **5–13 Model concepts.** Lesson 1 Cards 2 and 4; public/private keys and signatures at role level; Lesson 2 evidence cards. “Which statement are we least comfortable explaining?” Record for scientific clarification. - **13–22 Rehearse the model boundary.** Solve 17 × 19 and 437; complete “The small-number activity helps us illustrate …; it does not establish …”. Practise the coin limit and “not faster at everything”. - **22–33 Teach back** in triads (~3 minutes each). Prompts: “If quantum computers are powerful, why not stop updating devices?” · “If we can factor 437 in class, have we broken real encryption?” · “Why can a signed message still reveal a private note?” - **33–40 Adapt** without losing the outcome: one access adjustment, one likely misconception, one assessment response. No signups or home devices. - **40–45 Exit and next step.** Schedule a check-in after first delivery; record preparation and teaching time. **Teach-back rubric (0/1/2 each):** names security goal; explains conditional risk without hype; states model limit; checks understanding with a question; gives a safe next step. Record one observed phrase. Locally designed; not a credential. **Teacher exit notes:** (1) assessable outcome e.g. distinguish confidentiality/integrity — not “become quantum-safe”; (2) correct a risky analogy — coin ≠ interference, factoring 437 ≠ codebreaking; (3) honest readiness needs are useful; (4) reteach triggers: “a public key must always be secret”, “encryption means the sender is honest”, “quantum breaks everything today”; (5) optional online tools collecting pupil data need school/sector software, privacy and child-safety approval. --- # Family information **What is this learning about?** How digital information is protected and how emerging quantum computing may change some security methods, through fictional situations. **Why now?** Organisations are preparing for future cryptographic change. No promise of jobs or grades. **Will students hack systems or share passwords?** No. Paper, discussion and invented scenarios. Concerns go to a trusted teacher. **Device or internet at home?** Not needed for core lessons; printed materials available. **Do quantum computers already threaten every account?** No. Official 2026 guidance describes the capability as a future risk. Normal account security remains important. **Will student information be collected?** Teachers may use ordinary classroom responses to check learning. Named pupil information is not required by these resources and should not be shared with external providers by default. The school explains any research or additional collection and approvals. **Different format?** Ask the school contact (to be added by the school) about reading support, accessible print or oral responses. --- # Evaluation questions and administration **Baseline and final check — teacher key** (10–12 minutes; allow “not sure”; original formative questions, not a validated instrument). Use fresh copies of the answer-free student response sheet before Lesson 1 and after Lesson 3, without the glossary or lesson sheets. Keep agreed access supports unchanged; accept written, diagram or oral explanations. Keep responses and any matching identifiers school-held; do not send learner responses to QSFS or external providers. Score each question **0–2**, total **0–16**. For every question, **0** = no relevant response, “not sure” without relevant reasoning, or inaccurate reasoning; **1** = partly correct answer/reasoning that does not meet the full criterion; **2** = meets the question-specific criterion below. Relevant partial reasoning with “not sure” may earn 1; do not penalise uncertainty separately or award points for confidence. Record support and missing responses separately. These examples guide moderation, not automatic scoring. 1. **Public announcement’s date changes without permission — confidentiality, integrity or neither?** Answer: integrity. **2-point criterion:** identifies integrity and explains the unauthorised change; **1:** correct label without explanation or partially relevant reasoning. 2. **Signed message sent openly — must contents be secret?** Answer: no; signature and confidentiality are different functions. **2-point criterion:** says no and explains that a signature supports origin/alteration checks rather than hiding content; **1:** no with incomplete explanation. 3. **Public key published by its owner — secret leaked?** Answer: no; intended to be shared; private key must be protected and ownership verified. **2-point criterion:** explains public sharing is intended and distinguishes the protected private key; **1:** no without that distinction. Ownership verification is useful additional context, not an extra point. 4. **“Quantum computers are faster at every task.”** Answer: disagree; advantages are task-specific. **2-point criterion:** rejects the universal claim and explains dependence on the problem/algorithm and suitable hardware; **1:** rejects it with incomplete reasoning. 5. **Can every encrypted message already be read?** Answer: no; capability not established in current official guidance; schemes differ. **2-point criterion:** rejects the universal present-day claim and explains the conditional future threat to certain public-key methods, not all encryption; **1:** no with incomplete scope/timing reasoning. 6. **Why plan earlier for a long-lived private record than a public notice?** Answer: confidentiality lifetime and possible future decryption; the notice still needs integrity/authenticity. **2-point criterion:** links long-lived secrecy to possible future decryption of obtained vulnerable encrypted data and recognises a public notice still needs protection such as integrity/authenticity; **1:** identifies long-lived confidentiality but does not explain the comparison fully. Retention alone does not establish confidentiality lifetime. 7. **Evidence question for “quantum-safe forever”.** Answer examples: standards, covered functions/version, independent testing, update arrangements or limitations. **2-point criterion:** asks one specific checkable evidence question and explains why the absolute assurance is insufficient; **1:** a relevant but vague question or no reason. 8. **Strange login request today — ignore while waiting for upgrades?** Answer: no; trusted reporting. Present risks remain. **2-point criterion:** rejects ignoring it, names trusted authorised reporting and explains that future upgrades do not remove present risks; **1:** no or a safe route without the explanation. Report number assessed, matched responses, missing data, delivery differences and uncertainty. No causal or statewide claims from a small uncontrolled pilot. **Student experience items** (5-point scale + “prefer not to answer”): I can ask useful questions about a cybersecurity claim · I could take part fully · The examples helped me understand · I would like to learn more. Plus: What was confusing? What would make the lesson easier to access? Not evidence of mastery. **Teacher implementation log:** year level, lesson/date, attendance count, minutes delivered, preparation minutes, adaptations, access problems, repeated misconceptions, one de-identified example of good reasoning, one change. No pupil names or disclosures. **School review prompts:** improved explanations? participation without home internet/paid access? independent delivery after rehearsal? persistent misconceptions? workable time/materials? evidence and approvals needed before repeating? --- # Later primary adaptation (planned) Years 5–6: separate 45-minute foundation lesson — 5 min story, 10 min secrecy/change/source sort (Cards 1–3), 10 min repeated coin outcomes, 10 min what a model tells us, 10 min draw/explain. Link to VC2M5P01/VC2M5P02. Defer H operations and transition detail. Evaluate separately before offering. ## Review and source checklist Before delivery: teacher validates curriculum level and accessibility; subject expert checks wording; school confirms privacy/safeguarding; operator confirms permissions for external resources; versions/date recorded. Review time-sensitive statements before reuse. [ASD quantum computing](https://www.cyber.gov.au/publication/quantum-technology-primer-computing) · [ASD PQC planning](https://www.cyber.gov.au/publication/planning-for-post-quantum-cryptography) · [NIST PQC](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography) · [ASD vendor questions](https://www.cyber.gov.au/publication/post-quantum-questions-to-ask-your-vendors) · [Victorian school software policy](https://www2.education.vic.gov.au/pal/ict-software-schools-risk-assessment/policy) ## Evaluation approval gate — checked 9 October 2026 Before collecting research or externally initiated evaluation data involving Victorian government schools, confirm RISEC and institutional ethics requirements. RISEC states research for commercial or material gain will not be approved. Principal permission or anonymous collection alone does not establish exemption. Do not re-label research to avoid approval. [Department research process](https://www.vic.gov.au/conduct-research-department-education) --- Quantum-Safe Futures for Schools Framework (QSFS), founded by Michelle Magalona. Pilot draft v0.1 • October 2026 • For school review. Format: Markdown (.md).