PQC Triage: find the cryptography a quantum computer breaks first

PQC Triage — paste a dependency manifest, see which cryptography a quantum computer breaks first, and download a sealed migration plan.

Live app: https://pqc-triage.vercel.app
Source: https://github.com/aniruddhaadak80/pqc-triage

Every security team running post-quantum migration has the same problem, and it is not a
cryptography problem. It is a triage problem.

You have 400 dependencies. A handful of them matter. Somewhere in that list is an RSA-2048 key
that signed a session cookie, a curve that was never rotated, an HMAC comparison that leaks
timing. The algorithm is the easy part to find. Deciding which one to fix first, and writing
down why, is the part that gets skipped — and skipping it is why most migration plans die in a
spreadsheet.

So I built the thing I wanted during migration week: a triage instrument, not a dashboard.

The one idea

Quantum risk has a clock, and almost no tooling shows you the clock.

Harvest-now-decrypt-later means the attacker is recording your ciphertext today and decrypting it
later. So the useful question is never "is this algorithm weak?" It is "when does the data
behind this call site become readable, and when must I have moved by?"

PQC Triage plots every discovered surface as a fringe on a diffraction plate. Its horizontal
position is the year its captured data becomes decryptable. Its height is the engine score. Move
the horizon slider and every deadline moves with it, because the positions are computed from the
engine's own arithmetic, not from a lookup table.

That is the signature interaction. It is not decoration.

Three jobs, done end to end

No dashboard of decoration. Each of these is a real write against a hosted Postgres, and each
leaves an artifact behind.

1. A platform engineer imports reality. Paste a real package.json, requirements.txt, go.mod, Cargo.toml or pom.xml, plus a source excerpt. PQC Triage parses both, resolves every cryptographic call site to an algorithm, and reports 12/12 surfaces enriched from deps.dev and OSV.
2. A security lead sets the policy. Record a decision and a data shelf life per surface, and set the quantum-capability horizon. Below 2030 the NIST deadline dominates; above it, your own horizon does. The residual score recomputes as you triage.
3. A reviewer takes the artifact. Download the plan as Markdown, JSON or CSV, and replay the audit chain to confirm nothing was quietly edited.

The whole primary path is a real import, a real score, a real persisted decision, and a
downloadable plan — about ten seconds.

The engine is deterministic, and it cites itself

The scoring engine is versioned hndl@1.0.0. Given the same inputs it returns the same
numbers, which means a decision can be reviewed later and defended. Every factor carries its
source:

• NIST IR 8547 for the transition timeline — 112-bit public-key cryptography deprecated after 2030, disallowed after 2035.
• Gidney & Ekerå (2021) for the resource cost of factoring an RSA-2048 modulus, so "when" is derived from published estimates rather than vibes.
• Häner, Beunink & Joosten (2020) for what breaking discrete logarithms actually costs.

A few things I was careful not to do:

• RNGs are never labelled broken by Shor's algorithm. Shor targets factoring and discrete logarithms. Calling a CSPRNG "Shor-broken" is wrong, and a tool that says it is telling you it has not read the literature. Those surfaces score as supply-chain trust instead.
• Already-past deadlines render as "3.8y ago", never as negative years.
• Supply-chain risk scores as exactly neutral when there is no evidence — 0.5, not a guess.

An agent interface that cannot cheat

There is a JSON-RPC 2.0 endpoint at /api/mcp with 11 typed tools, and a console to drive it
in the browser.

The mutating tools call the same service functions the buttons call. An agent therefore cannot
reach a state a person could not, cannot write outside its own anonymous owner scope, and cannot
skip the audit chain. Every write takes an idempotency key, keyed per owner and per scope, so a
retried agent call replays instead of double-posting.

There is no login. Ownership is an anonymous HttpOnly cookie, and every query is scoped to it.
A verifier check proves another anonymous session gets a 404 on your survey, cannot write to it,
and cannot delete it.

Sealed, then verifiable

Every survey carries a genesis seal and a hash chain over its audit events. Export the plan and
the seal travels with it. Retire a survey and the chain advances — the tombstone is part of
the history, and a replay still verifies after the delete.

I like this because it makes the boring question — "did anyone change the numbers after triage?" —
answerable without trusting me.

Live data, labelled honestly

No API keys required, ever. Four live sources, each reporting live or fallback with the fetch
time:

Source	What it contributes
deps.dev	release and version metadata per dependency
OSV	published advisory records
arXiv	current quant-ph / cs.CR work
NIST news	standards announcements, filtered for crypto

When a source times out, the app shows a sealed dated sample and says fallback. It never
presents yesterday's cached answer as if it were live.

Built with

Next.js 16 on the App Router, React 19, Tailwind v4, strict TypeScript, Neon Postgres in
production and PGlite — a real Postgres compiled to WebAssembly — for local development and tests,
so the schema and the SQL are identical in both. No key is needed to run it.

The interface is deliberately quiet: Fraunces for display, Archivo for text, a monospaced face for
readouts, and a paper-and-spectral-band palette borrowed from the diffraction idea itself.

What I verified, and what I did not

Claims I can back up:

• 130 unit tests, tsc --noEmit and eslint clean, production build green.
• 12 Playwright tests across desktop and mobile, run against the deployed app: import, triage, export, publish, verify, delete.
• 105 live end-to-end checks against production on Neon Postgres, covering the public API, the MCP endpoint, ownership boundaries, publish/verify/retire, and every primary route.

Things it is not:

• Not a scanner. It reads what you paste; it does not walk your filesystem or your cluster.
• Not an assurance product. It does not certify anything. Disagreeing with a factor weight is a feature discussion, not a vulnerability.
• Rate limiting is a best-effort in-process counter and is documented as such in SECURITY.md.

Try it, then read the code

aniruddhaadak80 / pqc-triage

Import a real dependency manifest, see which cryptography a quantum computer breaks first, and commit the date you must migrate by.

PQC Triage

Find the cryptography a quantum computer breaks first — and the exact year you must migrate by.

Live app · GitHub · API · Agent · Issues

Post-quantum migration is a calendar problem wearing a technical costume. Nobody argues about whether RSA-2048 falls to Shor's algorithm; everybody argues about when, and the honest answer is "whatever year a cryptographically relevant quantum computer arrives" Most inventories never get that far, because the first hard question is where the cryptography is.

PQC Triage imports a real dependency manifest and a real source excerpt, resolves every cryptographic surface to an algorithm, scores each one against published quantum resource estimates and the NIST transition dates, and commits a sealed migration plan with a start-by year for every surface.

Zero API keys. Runs offline on an embedded Postgres. Every number carries its citation.

---

✨ Features

• Real inventory. Parses package-lock.json, package.json…

View on GitHub

If you have a manifest that has been sitting in a backlog, paste it in. The interesting part is
not the score — it is the sentence explaining which line of code you have to fix first.

Live app: https://pqc-triage.vercel.app
Repository: https://github.com/aniruddhaadak80/pqc-triage

---

Built as an entry for the Hacktoberfest 2026 Open-Source AI Challenge — powered by MLH and DEV,
presented by DigitalOcean. Infrastructure thanks to Neon for the hosted
Postgres and Vercel for the deployment. The scoring engine cites NIST IR 8547
and published Shor resource estimates; it does not replace a cryptographer's judgement.