Cryptographic Attribution and Immutable Decryption Provenance for Multi-Recipient Encrypted Document Distribution

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   The forensic watermark is the make-or-break: it must survive how documents actually leak — screenshot, print-scan, re-export, format conversion — and a watermark that only survives a byte-identical copy is trivially defeated

2. It gets worse

   Invisible-yet-robust watermarking is a serious research problem, and teams tend to build the crypto and under-build the watermark that the whole attribution depends on

3. Still reading?

   The offline, no-cloud-KMS, no-public-chain constraints rule out convenient shortcuts, so the ledger and key management must be genuinely self-contained

4. And the finisher

   A false attribution accuses the wrong person, so the binding and lookup must be cryptographically sound, not merely plausible

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  3/5

  Buildable. Not comfortably. There is a week in here you have not planned for yet.

  The cryptographic half — post-quantum signatures (ML-DSA), an append-only signed ledger, decryption binding — is buildable with existing PQC libraries, but the forensic-watermarking half is the genuinely hard part: an invisible, per-session watermark that survives the ways a document actually leaks (re-export, screenshot, print-scan, format conversion) is a serious research problem, and a watermark that only survives a byte-identical copy is easily defeated.

• Innovation scope

  4/5

  There is something genuinely new here. Do not bury it under another dashboard.

  Binding decryption-time forensic watermarking to post-quantum non-repudiation and an immutable offline ledger into one attribution chain is genuinely open, and the robust-watermarking design — surviving realistic leak channels while staying invisible — is the real intellectual contribution.

• Clarity

  5/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  Exceptionally precise: the threat model, the required watermark properties, the post-quantum requirement, the DLT audit layer, the full end-to-end workflow, and the strict offline/air-gapped, no-cloud-KMS, no-public-chain deployment constraints are all spelled out step by step.

• Acceptance potential

  4/5

  Strong footing before you have written a line. Try not to waste it.

  A strong pick — the spec is excellent, the post-quantum and offline framing lands hard with an MoD judge, and the attribution demo is compelling, but the watermark robustness is the make-or-break: a submission whose watermark survives only a byte-identical copy has solved the easy half, and a defence judge will ask how it survives a screenshot or print-scan.

• Effort

  Massive

  A semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.

  Broadcast encryption, per-session forensic watermarking, post-quantum signing, an offline tamper-evident ledger and a watermark-to-ledger forensic lookup is a large cryptography-plus-watermarking build.

• Demo-ability

  Easy

  Easy to demo — and so is everyone else's. Working is the floor here, not the achievement.

  Three identical-looking decrypted copies, then tracing one leaked copy back to the exact recipient via the offline ledger, is a concrete and genuinely impressive demo — and the air-gapped constraint makes the network-off proof dramatic.

• Data

  None supplied

  No dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.

  Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.

The demo they will have already seen 🪞

Somewhere around 70–160 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• The cryptographic half rests on standardised post-quantum algorithms with existing libraries, so signing and the ledger are buildable on solid foundations
• Tracing one leaked copy of three identical-looking documents back to the exact recipient is a concrete, memorable demo, made dramatic by the air-gapped constraint
• The post-quantum and offline framing lands directly with an MoD judge's priorities