Inspiration
I'm interested in cybersecurity and cryptography, and I wanted to build something for QuantumHacks that was technically substantial which is a project that actually touched real cryptography, a real database, and a real fintech problem at the same time.
The specific idea came from "harvest now, decrypt later": the fact that almost all financial systems today rely on RSA or ECDSA, which are secure against classical computers but breakable by a sufficiently powerful quantum computer using Shor's algorithm. The unsettling part is that an attacker doesn't need that computer today. They can steal encrypted data right now and hold onto it until quantum computers catch up. That reframes post-quantum migration from a future problem into a current one, and I wanted to build something that made that concrete instead of abstract.
What it does
QuantumVault scans a transaction database and flags every transaction still signed with a classical, quantum-vulnerable algorithm (RSA-2048, RSA-4096, or ECDSA-P256). From there, it can migrate a flagged transaction to ML-DSA-65, a real NIST- standardised post-quantum signature algorithm, live. It also runs a real benchmark comparing keygen/sign/encapsulate timing across RSA, ML-KEM, and ML-DSA, so the cost of migrating is measured, not assumed. There is also a plain-language panel explaining why RSA is vulnerable and why lattice-based algorithms currently aren't.
How we built it
The stack is Python, FastAPI, and SQLite, kept deliberately simple so the focus stayed on the cryptography rather than infrastructure. For the post-quantum side, I used liboqs- python, the Python bindings for the Open Quantum Safe project's C library — the same reference implementation used in a lot of real-world PQC work. RSA and ECDSA come from pycryptodome, as the classical baseline for comparison. The frontend is plain HTML/CSS/JS, no framework, so the whole app runs as a single FastAPI process.
Challenges we ran into
Two things ate most of my time, and I think both taught me a lot more about development.
First, the package name isn't what you'd guess. I initially had pyoqs in my requirements file. It looks like the obvious name for Open Quantum Safe's Python bindings, but it doesn't exist on PyPI. The real package is liboqs-python. I lost close to an hour before realizing the problem was the dependency name and not my code.
Additionally, deploying a package that wraps compiled C code is a fundamentally different problem than deploying pure Python. liboqs-python needs to compile liboqs, a C library, using cmake — which worked fine in GitHub Codespaces since cmake was already installed there. It failed immediately on Render's free-tier native Python environment, which doesn't allow installing system packages. I switched to a Docker-based deploy and wrote a Dockerfile that explicitly installs cmake, build-essential, ninja-build, and (after a second failed build) libssl-dev, since liboqs also needs OpenSSL headers I hadn't accounted for. Only after all of that did the deploy actually succeed.
Accomplishments that we're proud of
Getting real post-quantum cryptography working, not a mock. Every RSA and ML-DSA operation in this project is a genuine cryptographic computation — real key generation, real signing, using liboqs, the actual reference implementation a lot of real-world PQC work is built on. Nothing here is simulated numbers or placeholder data.
The benchmark data actually surprised me. I expected post-quantum crypto to just be "more secure but slower." Instead, ML-DSA-65 key generation ran nearly 6,000x faster than RSA-2048 — the real trade-off is signature size, not speed. That's a finding I only got because I measured it instead of assuming it, and it's a more interesting story than I expected to have.
Getting through the deployment problems without giving up on doing it properly. liboqs-python wraps compiled C code, and Render's free tier doesn't allow the system packages it needs by default. I could have given up and just demoed it locally, but I got a proper Docker-based deploy working — compiling liboqs from source, with the right build tools — so there's a real, live, public URL for anyone to check.
Keeping the scope honest, it would have been easy to bolt on user accounts or a fake blockchain layer to make it "look bigger." I deliberately kept it to database, audit, migration, and benchmark — fewer things, done for real, rather than more things half-simulated.
What we learned
That post-quantum migration isn't a free win, as I went in with a vague assumption that the new algorithms would just be "better" across the board, meaning more secure and done. Actually running the benchmarks showed something more specific: ML-DSA-65 key generation is dramatically faster than RSA-2048, but the signatures are over 10x bigger. That's a real cost, and it's the kind of thing you only find by measuring, not by reading about it.
I also learned that "pip install" doesn't mean the same thing for every package. Pure Python packages just work. Packages wrapping C code, like liboqs-python, need the actual system-level build tools — cmake, a compiler, OpenSSL headers — and if your deploy environment doesn't have those, it doesn't matter how correct your code is, the build just fails. I hit that three separate times before I got it right, and each failure taught me something I didn't know I needed to know beforehand.
Its also that the deployment problem is often harder than the actual feature you're building. I spent more time getting liboqs to compile on Render than I spent writing the migrate endpoint. That wasn't what I expected going in.
What's next for QuantumVault
If I kept working on this past the hackathon:
Bigger, messier dataset: 20 transactions proves the idea, but a real system would need to handle thousands, and audit performance at that scale is a different problem Bring ML-KEM into the actual migration flow, not just the benchmark. Right now it's benchmarked but not used for key exchange anywhere in the app Keep a real migration history instead of overwriting the old signature so you can actually see what changed and when Look into hybrid signing (classical + post-quantum together) since that's closer to what real migration guidance currently recommends over a hard cutover Show this to someone who actually works in security or fintech and see if the audit logic holds up against how a real system would think about risk
Log in or sign up for Devpost to join the conversation.