I build secure software. Then I prove it works.
Sydney-based engineer. Backend, cryptography, and offensive security. I build production systems and then break them to find the gaps.
Who's writing this
I like understanding systems from both sides. Building software is only half the job — the other half is asking what assumptions it depends on, what happens when those assumptions fail, and whether I can actually explain why. That's taken me through backend development, applied cryptography, quantum computing experiments, and offensive security. When I'm not building products, I'm usually solving CTF challenges or implementing ideas from research papers just to see how they actually work.
const developer = { name: "Abhinav Kumar", based_in: "Sydney, Australia", stack: ["Python", "React", "TypeScript", "FastAPI"], security: ["web exploitation", "binary exploitation", "applied cryptography"], philosophy: "if I can't explain how it fails, I don't understand it yet", currently: shipping("real, working systems") };
How I work
Build
Start small. Make it work.
Measure
Untested is unfinished.
Break
Abuse it before they do.
Improve
Software survives contact with reality.
Experience & Methodology
A chronological record of operations and the core principles guiding my technical execution.
- Verified REST/Auth flows under load.
- SQL validation & schema mapping for data integrity.
- Live debugging of integration failures in production-ready cycles.
What I actually use
Projects that taught me something
Each of these forced me to actually understand a system, not just use a library.
Haven
Every task is encrypted before Haven's server ever sees it — and there's a page that proves exactly that.
Why: I wanted to know what "zero-knowledge" actually means in practice, not just in a whitepaper.
Problem
"We encrypt your data" is a line every app puts in its privacy policy. Almost none let you actually check it.
Approach
Built a "you vs. the server" panel that queries the real stored record and renders exactly what the backend has on disk.
Result
What the server sees is ciphertext, full stop — AES-256-GCM, key derived via PBKDF2-SHA256 at 600,000 iterations.
MeowMentor
A Safari extension that watches me solve problems on LeetCode and eight other judges, then coaches instead of solving.
Why: I wanted hints that teach the pattern, not ones that just hand me the answer.
Problem
LeetCode, Codeforces and AtCoder all render their editors completely differently. A coach that only works on one site isn't a coach.
Approach
Built a detector that tries dedicated adapters first — LeetCode, Codeforces, AtCoder, CodeChef, GeeksforGeeks — then falls back to a generic one for the rest, verified against real DOM captured through an actual Safari session instead of guessed selectors. Hints escalate through four levels: a Socratic question, then direction, then pattern, then a full solution only on request.
Result
Seven of nine platforms have real, DOM-verified detection. Nudges fire on stuck time and repeat failures, not a timer, and every problem stays in chrome.storage.local: nothing leaves the machine unless you turn on the optional public profile sync.
Shor's RSA Cracker
Factored RSA by hand, then classically, then on IBM hardware.
Why: I wanted to understand why RSA actually breaks, not just read that it does.
Problem
Anyone can claim a quantum simulator is correct. Trusting my own code to grade my own code isn't proof of anything.
Approach
Built the statevector simulator from scratch — gates, entanglement, QFT — then diffed the same circuits against Google's Cirq state by state.
Result
Matched Cirq to floating-point precision. The real IBM hardware run came back noisier, which is exactly the point.
Ashfaq Policy & Affairs
A foreign-policy blog with an AI editor built into the writing flow, not bolted onto the CMS.
Why: Built for a policy researcher. The interesting part turned out to be the writing tool, not the blog.
Problem
AI drafting tools either write the whole article for you or ignore your voice completely, and both produce copy that reads like it.
Approach
An in-editor AI copilot (draft, continue, proofread, brainstorm, SEO check) scoped to only that article's text, plus a dedicated humanize pass that hunts down specific tells — rule-of-three padding, filler phrases like "stands as a testament" — sentence by sentence instead of doing a generic rewrite. Reader-facing summary, takeaway and Q&A tools answer strictly from the article text.
Result
Articles keep the writer's actual voice and hedges instead of flattening into generic AI register, and every reader-facing answer traces back to a sentence that's actually on the page.
Threshold Signatures
Kelsey, Lang & Lucks published this threshold-signature scheme in 2024. I built it.
Why: papers get a lot clearer once you've had to debug them.
Problem
A "multi-party" signing demo is easy to fake — one shared JS array pretending to be three signers proves nothing.
Approach
Ran each signer in a genuinely separate browser tab with no shared memory, talking only over BroadcastChannel.
Result
k-of-n threshold signing works across isolated tabs, with every Winternitz signature and Merkle proof computed live.
Paste a key.
Watch it break.
Factor and decrypt in the browser. No data leaves your machine. This is slow by design — the gap between instant and never is why RSA works. The prefilled example is a toy 12-bit key; find a sterner one elsewhere on this site and paste it in.
Things worth writing down
Things I changed my mind about
AES was the hard part of secure software.
Key management is the real fight.
Reading a cryptography paper meant understanding it.
Implementation reveals the hidden assumptions.
A quantum computer would make short work of real RSA keys.
Today's hardware can barely factor toy numbers — the gap between "possible in theory" and "possible today" is enormous.
Code I've put into the world
Is it actually up
SEC_PLAYGROUND_▋
Let's build something
name: "Abhinav Kumar",
email: "pinku2c@gmail.com",
github: "github.com/iabhi92",
linkedin: "linkedin.com/in/iabhi92",
based_in: "Sydney, Australia"
};