Account note:
Encryptorium has moved to @encryptorium.
This account is now only parked for continuity. For new posts on applied cryptography, PQC, ZK security, and the Book of PQC, please follow @encryptorium.
I need to get this off my chest: the way some people talk about post-quantum migration genuinely grinds my gears.
Not because they are worried about quantum computers. They should be. Not because they ask about hybrid algorithms. That is a valid question.
What grinds my gears is the confidence.
People jump straight to "which algorithm should we roll out?" before they can answer the much more boring question: "where are we even using cryptography?"
I keep seeing the same pattern. Hybrid this, PQC-ready that, apply it across the board, put it on the roadmap, add it to the slide deck. It all sounds serious until you ask where the crypto actually lives. Then suddenly the answer is somewhere between a config file, an old diagram, a vendor promise, and "someone probably knows."
That is the bit that has been stuck in my head for weeks.
"We can have a look at the config file."
That is not a migration strategy. That is archaeology.
And when you mention a cryptographic bill of materials, people treat it like paperwork. "We do not need that. We have the config." No. You have fragments. You have assumptions. You have whatever survived the last reorg, migration, outsourcing wave, and urgent production fix.
The code you wrote is only part of the story. The uncomfortable part is the crypto buried in vendor libraries, firmware, appliances, SaaS dependencies, backup systems, old archives, and code-signing chains nobody has touched in years.
And somehow, this is all supposed to be solved by "just slapping on PQC."
That phrase drives me insane.
Slap it on where? On the thing nobody has inventoried? In the system nobody owns end-to-end? Across dependencies nobody can fully explain?
Post-quantum migration is not a paint job. It is not algorithm shopping. It is not a checkbox that says "PQC ready" because those words appeared in a vendor PDF.
I am not anti-PQC. I am very much pro-PQC. Harvest now, decrypt later is real. The migration needs to happen. The timelines are not generous.
But I am anti-pretending.
If you cannot answer "where do we use what," you are not migrating.
You are guessing in a more expensive font.
On April 9, a paper proposed quantum-safe Bitcoin spends with no soft fork.
QSB is the escape hatch. It protects legacy coins already inside a QSB-locked output, not coins still in ECDSA wallets.
Full breakdown:
https://t.co/AZeYVR6DY3
#PostQuantumCryptography#Bitcoin
The place many rollup teams surface less than they should in threat models is the final L1 verifier.
Teams choose their prover, proof system, and recursion strategy. But if the proof Ethereum ultimately accepts is Groth16 on BN254, the post-quantum security of that final on-chain acceptance path is bounded by BN254's pairing-based security, not by the hash-based security of the STARK layer upstream.
A STARK prover wrapped in a Groth16/BN254 verifier is not post-quantum end to end. That dependency is still underexposed in many rollup security discussions.
New on Encryptorium: too much of the PQC market sells urgency before discovery.
NIST, NCSC, CISA say the opposite — inventory and crypto-agility first, then algorithm choice.
Three fear patterns named, with the practitioner counter to each.
https://t.co/28ZRPKi9qq
Google says breaking Bitcoin's ECDSA signatures takes 500,000 physical qubits. That is ~20x fewer than prior estimates.
But the paper is not a timeline forecast. It is a cost estimate.
Full breakdown, 16 min: https://t.co/d5I4zKD70j
#PostQuantumCryptography#Bitcoin
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.
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.
https://t.co/nb5vXifx9g
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.
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.
https://t.co/MKOqJmCF4i
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.
Finally just about done with my deep hardware wallet testing for security-conscious developers and protocols.
Hardware wallets video and article on the research coming soon.
Here is a sneak peek.
If anything looks wrong from this snapshot, now's the time to let me know!
Want to harden your systems with prescriptive security configurations? Learn how CIS Benchmarks provide a structured approach to secure OS, cloud, databases, and more—aligned with NIST, ISO 27001, PCI-DSS, and SOC 2.
https://t.co/K269yWIpoA
I absolutely agree! This also ties into shift-left security, where the goal is to incorporate security as early as possible in the development cycle. Not only does this create more secure code, but it can also reduce costs and prevent headaches later on.
People are often confused when I tell them they should compete in audit competitions to become better developers.
The truth is, the best smart contract developers are security minded.
Getting better at security == Getting better as a developer
Web Clipper lets you highlight important passages, and select the elements you want to save to Obsidian.
Your highlights are saved, so you can revisit them when you return to a page.