AndiR16 🤝

STARKs are built on hash-based commitments and coding-theoretic machinery like FRI, which avoids the main Shor-vulnerable assumptions behind pairing- and discrete-log-based proof systems. But some implementations add a final SNARK wrapper for cheaper on-chain verification. RISC Zero’s docs describe compressing a STARK proof into a Groth16 proof, and explicitly mark that path as not quantum-safe. “We use STARKs” is not enough to make a system post-quantum. You have to trace the full verification pipeline.

Third @hackernoon article landed. 😊 This one is different: research notes from an unfinished paper, shared to invite criticism, counterexamples, and discussion. My working claim is that post-quantum ZK is not mainly a parameter problem. It is an architecture problem. The real question is which layer of the proving stack carries the quantum-vulnerable assumption, and whether that layer can actually be migrated in a deployed system. I walk through Groth16, Boojum, and STARKs, and ask what collapses, what degrades, and what may be modular enough to migrate. Hash-based does not automatically mean quantum-safe. Modularity may be the difference between migration and a full rewrite. hackernoon.com/post-quantum-z…

Second @hackernoon piece is live. I broke down Avihu Levy’s QSB construction: quantum-safe Bitcoin spending using existing script rules, with no soft fork. The trick is grinding inputs until RIPEMD-160 yields a value that parses as a valid DER-encoded ECDSA signature, giving ~2^118 second-preimage resistance under Shor. The construction works. But it costs roughly $75–150 in off-chain GPU compute per transaction, does not help Taproot, and does not scale to full-network use. A last-resort escape hatch, not a fix. The clearest takeaway: The best in-script workaround still points to the need for protocol-level changes like BIP-360. hackernoon.com/qsb-could-save…

My first @hackernoon article is live, and I won’t pretend I’m not grinning. I broke down Google Quantum AI’s new paper: fewer than 500,000 qubits to break Bitcoin’s secp256k1, a 20× cut from prior estimates. A resource estimate is not a timeline. Migration is the bottleneck. hackernoon.com/googles-quantu…

Very proud to see @hackernoon share my article. HackerNoon picked up my article on Google Quantum AI’s new Bitcoin paper. I wrote it to cut through the hype and get to what actually matters: lower resource estimates are important, but migration is still the real bottleneck.

What Google’s new quantum paper really says about Bitcoin: lower attack costs, no immediate break, and why Taproot exposure matters. #cryptocurrency #pqc...Show more

11/11: If you're working on PQC migration, ZK system security, or post-quantum compliance, I'd like to hear from you. What's hard? What's missing? encryptorium.com Onward. @encryptorium

Quick question for writers publishing with @hackernoon: How long do your stories usually stay in editorial before they go live? I’ve got 2 in there right now, one for 10 days and one for 11, and I’m curious whether that is pretty normal or unusually long.

Here are the PQC resources that really shaped how I think about post-quantum migration so far. If I missed your favorite PQC resource, paper, or person to follow, drop it in the replies so others can learn from it too 👇 🧱 Standards/foundations The PQC project from @NISTcyber is still the anchor. If you want to understand what is actually standardized, start with the real documents: FIPS 203 (ML-KEM) FIPS 204 (ML-DSA) FIPS 205 (SLH-DSA) I would also add NISTIR 8413, because it helps explain how we got here and why certain schemes made it through the process. If you want one person whose posts often sharpen the discussion rather than smooth it over, follow @hashbreaker. 🗺️ Migration/planning For migration thinking, the roadmap from @NCSC is one of the clearest public resources I have seen. NIST IR 8547 is also useful because it pushes the conversation away from "which shiny new algorithm should we pick?" and toward inventory, transition planning, dependencies, and system impact. That shift matters. The biggest mindset change for me was realizing PQC migration is not mainly an algorithm problem. It is a systems problem. If you care about how large organizations are framing urgency right now, the recent Google migration push from @argvee and @SchmiegSophie is also worth reading. 🌍 Real-world deployment/what shipping looks like If you want a signal on what actual deployment looks like instead of abstract roadmap talk, I keep coming back to: posts and writing from @bwesterb @signalapp's PQXDH writeup Apple's PQ3 writeup Those helped me understand that the real story is not "PQC someday." The real story is that migration has already started in places users touch every day. 🧠 Threat/why now For threat calibration, I found it useful to read both the standards side and the resource-estimate side. Craig Gidney's work and posts @CraigGidney helped a lot here, especially for translating quantum headlines into something more concrete. And again, @hashbreaker is valuable because he keeps pressure on the complacent "we have plenty of time" framing. 🛠️ Hands-on/implementation If you want to get your hands dirty instead of only reading papers: Open Quantum Safe / liboqs work around cryptographic inventory and CBOMs from @PQCAorg deployment commentary from @bwesterb That combination is helpful because it covers standards, implementation reality, and rollout friction, not just theory. 📚 A few papers/docs I would actually recommend people read FIPS 203, 204, 205 NISTIR 8413 NIST IR 8547 the @NCSC PQ migration timelines the Google migration posts from @argvee and @SchmiegSophie @signalapp's PQXDH writeup Again: not a complete list. Just the resources that genuinely helped me think more clearly about PQC. Biggest shift for me: PQC migration is not mainly about choosing a new algorithm. It is about inventory. It is about dependencies. It is about crypto agility. What PQC resources shaped your thinking the most?

1/5: My take on the QSB paper by @avihu28 (@StarkWareLtd), dropped April 9. It shows how to build a Shor-resistant spend path inside today's legacy Bitcoin Script, no soft fork. Clever and narrow, it makes the case for a protocol-level PQ signature louder, not quieter.

PQC migration plans have a ZK blind spot. NIST IR 8547 (draft), the UK NCSC's 2025 PQC timeline, and EU Recommendation 2024/1101 all describe PQC migration roadmaps. None of them discuss zero-knowledge verifiers or ZK verification infrastructure. That matters because some deployed ZK systems still rely on quantum-vulnerable elliptic-curve/pairing-based components. These are not always things you can swap as easily as certificates. "We use STARKs" is not always a complete answer either. RISC Zero's docs explicitly note that their STARK-to-SNARK layer uses Groth16/BN254 and is quantum-vulnerable. Polygon zkEVM also ends with a final SNARK validity proof on-chain. Commitment scheme choice, verifier upgradeability, and proof composition are already PQC decisions. The NCSC's target for full migration is 2035. For verifier infrastructure, replacement paths may take years. Full article: encryptorium.medium.com/pqc-migration-… #PostQuantum

1/11: I've been working on something for a while. What started as scattered writing and tools around post-quantum cryptography has taken a shape I'm genuinely happy with. Encryptorium: an applied cryptography research platform focused on the problems practitioners actually face during PQC migration. Here's what it is and why it exists.

I already wrote a thread breaking down Google Quantum AI's paper on breaking Bitcoin's elliptic-curve signatures. This blog post goes deeper. It covers what the thread couldn't fit. Taproot's specific exposure window: P2TR addresses leak tweaked public keys on-chain, giving an attacker indefinite offline time. The full hardware gap: 446x more qubits than anything that exists today. And where post-quantum migration actually stands across Bitcoin, Ethereum, Algorand, Solana, and QRL. The paper is real science. Most headlines are not. This piece walks through what the numbers actually say. encryptorium.medium.com/googles-quantu…

1/10: Google Quantum AI published a whitepaper estimating the resources a future fault-tolerant quantum computer would need to break the elliptic-curve cryptography (secp256k1) used by Bitcoin and other cryptocurrencies. The reaction has been predictable. "Bitcoin is dead" headlines, alert emojis, panic. The paper is real science. The panic is not. Here is what it actually says, what it does not say, and what is already being done about it.

Important early work-in-progress on the post-quantum security of modern ZK systems. Sharing because this deserves scrutiny and discussion. @RareSkills_io @zeroknowledgefm @__zkhack__ @LeastAuthority @Zac_Aztec @AnnaRRose @zksecurityXYZ @KoalateeCtrl

12/12 Particularly interested in feedback from people thinking about ZK system design, deployment constraints, recursion, FRI / Fiat–Shamir / QROM, and real migration paths. encryptorium.medium.com/post-quantum-z…

1/12 I’ve been working on a paper about the post-quantum security of modern zero-knowledge proof systems. Progress on the full paper will slow for a while as I focus on the CISSP, but I didn’t want the core ideas to disappear into private notes.

Some personal reflection today. Roughly 214 days ago, I started what I called the 1001-day challenge. The idea was simple: introduce deliberate consistency into my life and see whether sustained daily effort could meaningfully change my direction. At the time, cryptography and research still felt like something slightly “ahead” of me — something I wanted to grow into. So I began posting daily progress updates. Not for performance, but for accountability. To show up every day. To study mathematics again. To go deeper into cryptography and post-quantum topics. To actually build, write, and understand instead of just planning to. Looking back now after more than 200 days, I can honestly say: The experiment worked. The last months were intense — countless early mornings, late evenings, weekends spent studying, coding, reading papers, rewriting notes, failing, retrying, and slowly understanding things that once felt completely out of reach. And the effects went far beyond spare-time learning. My professional life changed. My understanding of cryptography deepened dramatically. Research moved from an abstract goal to something I actively do. Writing papers became normal. Rust development became part of my daily toolbox. Post-quantum cryptography and long-term security questions have increasingly become part of my day-to-day work. Somewhere along the way, the boundary between career, interest, and curiosity disappeared. I realized something unexpected: I am already at the point I originally hoped to reach after 1001 days. I genuinely enjoy what I’m doing — both in my job and outside of it. I wake up wanting to continue learning. I spend my time working on problems I care deeply about. And I can clearly see a long-term path forward. Because of that, the daily posting itself has started to feel repetitive. The purpose of the challenge was never counting days — it was building direction, discipline, and identity. And once those are established, the counter becomes less important than the work itself. So this is not an announcement that anything is stopping. Quite the opposite. I will continue: • studying mathematics and cryptography daily • working on research papers • publishing tools and experiments • writing technical blog posts • contributing to the ecosystem • exploring PQC and ZK systems • learning, building, and improving What will change is the format. I will stop the daily progress posts and instead share milestone updates from time to time — meaningful progress, publications, releases, insights, and research developments. The 1001-day challenge evolves from a public streak into a long-term roadmap for the next five years. Another thing that became very clear during these 200+ days: None of this happens alone. I owe enormous thanks to the people and communities that shaped this journey: @0xFlint_ — for the inspiration to post consistently and openly share progress. @LeastAuthority — for the MoonMath Manual, which became a constant companion throughout this journey. @Jeyffre — for inspiration, guidance, and showing what long-term dedication in this space can look like. @RareSkills_io — for the ZK book and outstanding educational resources. @RareCodeAI — your Rust course fundamentally changed my ability to build and experiment. @zeroknowledgefm and especially @AnnaRRose — for making complex ideas accessible and for countless hours of learning through conversations and podcasts. @__zkhack__ — for lowering the barrier to entry with incredible resources and community energy. @Zac_Aztec , @aztecnetwork , and @NoirLang — for pushing the ecosystem forward and making privacy-preserving technology tangible for builders. And honestly, many, many more people, researchers, builders, and community members who shared ideas, papers, feedback, encouragement, or simply conversations along the way. The last 200+ days were intense — many hours invested every single day — and it showed. It changed how I work, how I think, and where I’m heading. But this is not a finish line. If anything, it feels like the real journey is just beginning. The outlook from here is simple: write more, build more, publish more, collaborate more — and continue growing steadily within this field. Always open to collaboration, discussion, and shared research. Dedication compounds. Consistency works. And sometimes disciplined curiosity quietly reshapes your life faster than expected. Onward.

Privacy by Design is not a buzzword. It’s a discipline. A mindset. And honestly, a responsibility. Ann Cavoukian’s 7 principles of Privacy by Design were defined decades ago — and they are more relevant than ever. Yet I keep seeing projects (especially in tech, Web3, AI, and “data-driven” products) treating privacy as: • a legal checkbox • a settings page added later • or worse: a trade-off against usability or innovation That completely misses the point. Privacy by Design means: 1️⃣ Be proactive, not reactive Privacy incidents shouldn’t be “lessons learned after the breach.” If privacy is only addressed once users complain, you already failed. 2️⃣ Privacy as the default No dark patterns. No “opt-out if you find it.” If a user does nothing, their privacy should still be protected. 3️⃣ Privacy embedded into architecture Not bolted on. Not wrapped around. Built into protocols, data flows, storage models, and trust assumptions — end to end. 4️⃣ Positive-sum, not zero-sum Privacy vs security is a false dilemma. Privacy vs usability is a lazy one. Good design gives you both. 5️⃣ End-to-end lifecycle protection Collection, processing, sharing, retention, deletion. If you only think about encryption at rest, you’re not done thinking. 6️⃣ Visibility & transparency Users should be able to understand what happens to their data — not reverse-engineer your intentions from marketing pages. 7️⃣ Respect for users This is the core. If your business model depends on users not noticing what you’re doing — that’s not innovation, that’s extraction. What worries me most is not that privacy is “hard”. It’s that many teams don’t even ask the right questions early enough. Privacy by Design isn’t something you “add later”. By then, the architecture has already made its choices. If you’re building systems today and ignoring these principles, you’re baking future failures directly into your stack. Privacy isn’t the enemy of progress. It’s the foundation of trust — and without trust, nothing scales.

Hotfix shipped: zk-mutant v0.1.1 ✅ Turns out: operators inside comments can create a ton of noisy mutants 😅 v0.1.1 now ignores // ... + /* ... */ when discovering mutants — much cleaner inventories. mutorium.com/blog/zk-mutant… @MutoriumLabs @NoirLang #MutationTesting