Cryptography · SIH 2026 · prototype · 2026

ECDAT

Takes a cryptographic inventory and ranks each asset 0 to 100 for post-quantum migration urgency, naming the NIST replacement. Every score can be opened up and inspected.

Problem: Organisations moving to post-quantum cryptography need to know which systems to migrate first.
What I built: An engine that scores every cryptographic asset 0 to 100 for migration urgency and names the NIST replacement, with each score explainable.
Outcome: Pitch-round prototype for SIH 2026.
Role: Team lead

Tech: Python, FastAPI, Next.js, TypeScript, CycloneDX, Docker

Repository

Why it exists

Encrypted traffic can be copied today and read later, once a large enough quantum computer exists. People call this "harvest now, decrypt later". For anything that has to stay secret for ten years, the deadline for moving to post-quantum cryptography has already started.

Finding cryptography inside an organisation is mostly a solved problem. Open-source scanners will walk your code and hand you a full inventory in a standard format (a CycloneDX cryptography bill of materials). Then you are looking at a thousand findings with no idea which one to fix first.

ECDAT (Enterprise Cryptographic Discovery and Analysis Tool) is the step after the scan. We built it for Smart India Hackathon 2026, problem statement SIH26164 from the National Technical Research Organisation.

What it does

ECDAT reads the inventory and ranks it.

It scores each cryptographic asset from 0 to 100 for migration urgency.
It sorts assets into three buckets: Fix first, Plan migration, and Monitor.
It names the replacement for each one from the finalised NIST post-quantum standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204) or SLH-DSA (FIPS 205).
Every score can be opened up. Click it and you see the factors that built it, the input each factor read, and the arithmetic.

That last part is the point of the project. A migration decision has to survive an auditor or a board asking "why this one first?" A score you can't explain is a score you can't defend.

How the score works

The score is the sum of five bounded factors:

Quantum vulnerability. Is the algorithm broken by Shor's algorithm, weakened by Grover's, or already safe?
External exposure. Internet-facing assets are where ciphertext gets harvested first.
Data lifetime. Data that must stay secret for twelve years can't wait twelve years to be protected.
Dependency blast radius. How much breaks if this asset changes?
Migration effort. A quick fix on a dangerous asset gets a small bonus, so easy wins move up the queue.

Some of these are facts a scanner can't know, like how long data must stay secret or whether an endpoint faces the internet. ECDAT treats those as human-owned input and merges them with what the scanner found.

What exists today

It is a prototype for the SIH pitch round. The demo shows a ranked list of assets and a detail view that breaks down any score. The sample inventory is hand-made to look realistic, but the scores and recommendations are computed live from it. An optional mode runs a real open-source scanner against a sample app and feeds the output through the same engine. The scoring logic has an automated test suite.

The public repository holds the write-up only (README, vision and highlights). The demo code isn't in it.

What's unfinished

Everything past the scoring engine is still a plan: a dependency graph of keys, certificates and services, an ordered migration roadmap, an executive view, re-scoring on every pipeline run, and a lasting evidence trail for audits.