Term Project Report — CryptoVault (Secure Build)

Fill in every section. Keep the headings. Total 100 pts + up to 5 bonus (see rubric at the end). This is team work (2–3, nested in your House). Do not share your report or code with other teams. This is a "build it right" project: you are graded on correct composition of primitives, not features or polish. Each section below maps to a rubric line — for every primitive, show where in the code it lives and why your choice avoids the exact failure mode its weekly lab demonstrated.

Cover

AI-tool usage disclosure

Academic integrity: state how you used any AI tools (ChatGPT, Copilot, etc.) — e.g. searching, coding, translating, drafting. "None" is a valid answer.

1. Design Doc — System & Trust Boundary (part of §Demo & report clarity, 10 pts)

(one diagram + ~1 page)

• What the app does: the vault/note-sharing flow in one paragraph.
• Diagram (insert image): client(s), server, data store; where each key lives and for how long; the trust boundary — mark exactly where plaintext (and the symmetric key protecting an entry) is never allowed to appear (server memory? network? disk?).
• Key inventory: for every key/secret (password-derived key, per-entry data key, sharing keypair, signing key, TLS material) state: how it's derived/generated, where it's stored, and who can see it.

2. Password KDF (13 pts — Wk2)

• Why this is correct: why these parameters resist offline GPU cracking.
• Failure mode avoided (Wk2): why you did not use a raw/fast hash (MD5/SHA-256/HMAC-as-KDF) — the exact thing that made the Wk2 leaked-DB crack fast.

3. AEAD at Rest (15 pts — Wk4 / Wk6)

• Why this is correct: how a fresh, unique nonce is guaranteed for every encryption, and how tampering is detected on decrypt (tag verification).
• Failure modes avoided (Wk4/Wk6): why not raw CBC (bit-flip malleability), and why not a fixed/counter-reused nonce (the catastrophic GCM nonce-reuse from the Wk6 material).

4. Key Exchange / Key Wrapping for Sharing (15 pts — Wk5 / Wk10)

• Why this is correct: trace the shared entry's data key from A to B and show it is never transmitted or stored in the clear — only wrapped/agreed.
• Failure modes avoided (Wk5/Wk10): how a MITM can't silently substitute keys (Wk5), and correct RSA-OAEP / hybrid use — no reused ephemeral, no textbook RSA (Wk10).

5. Digital Signatures on Shared Entries (15 pts — Wk3 / Wk11)

• Why this is correct: the recipient verifies authenticity + integrity, and the sender can't repudiate. If ECDSA, state how malleability (low-S normalization) and nonce handling are managed.
• Failure modes avoided (Wk3/Wk11): why not hash(secret + message) (length-extension forgery, Wk3), and how you avoid ECDSA nonce-reuse key recovery (Wk11).

6. Transport Security (12 pts — Wk12)

• Why this is correct: every client–server link is authenticated and encrypted; no plaintext-HTTP fallback.
• Failure mode avoided (Wk12): why your client does not skip certificate/hostname validation (the exact cert-bypass MITM from Wk12).

7. End-to-End Composition (20 pts — the heaviest criterion)

Show the WHOLE share-an-entry flow is secure as a system, not just primitive-by-primitive.

• Trace one full "share entry" operation step by step: KDF → AEAD(at rest) → key exchange/wrap → signature → TLS, naming which primitive does what at each hop and which key is in play.
• Composition argument: why no plaintext and no bare symmetric key ever crosses the trust boundary you drew in §1 — end to end, including the server's view.
• Where the seams are: the one or two points where two primitives meet (e.g. the data key handed from AEAD to the key-wrap step) and why that hand-off is safe.

8. Crypto-Agility Note (stretch — +5 bonus, capped at 100)

(½–1 page — Wk15)

• Which primitive(s) above are broken by Shor's (asymmetric: your key exchange + signatures) vs. merely weakened by Grover's (symmetric/hash: double the parameter).
• What you'd swap in to be PQC-ready (e.g. ML-KEM for the key-exchange step, a hash-based/lattice signature for §5) and what stays.

9. Conclusion & Reflection

• Residual risks and what you'd harden next.
• Lessons learned composing primitives you'd previously only broken.

Peer-contribution ratings (required — see project/README.md)

Each member privately rates every teammate (incl. self): Full / Most / Some / Little + a one-line justification. Attach separately or here; the team mark is scaled per member by the averaged rating.

Grading rubric (100 + 5 bonus)

Total: 100 (+5 bonus, capped so the total cannot exceed 100).

All work stays within the ethics policy — your own team's app and test accounts only.