Quantum Security @QuantSEC01

The science behind the quantum threat, in plain terms Shor's algorithm. Solves factoring and discrete logarithms exponentially faster than any known classical method. That's what breaks RSA and elliptic curves, including the ones wallets use. Grover's algorithm. Speeds up brute-force search, but only quadratically. AES-256 and SHA-256 stay safe with large enough keys. Lattices. ML-KEM, ML-DSA and Falcon rely on latticeproblems that no known algorithm, classical or quantum, solves efficiently. Hash-based signatures. SLH-DSA and Winternitz rely only on hash functions, the most conservative security assumption there is. Error correction. Real qubits are noisy. Below a certain error rate, adding more qubits makes computations more reliable, and that's the threshold labs are now crossing.

The science behind the quantum threat, in plain terms Shor's algorithm. Solves factoring and discrete logarithms exponentially faster than any known classical method. That's what breaks RSA and elliptic curves, including the ones wallets use. Grover's algorithm. Speeds up brute-force search, but only quadratically. AES-256 and SHA-256 stay safe with large enough keys. Lattices. ML-KEM, ML-DSA and Falcon rely on latticeproblems that no known algorithm, classical or quantum, solves efficiently. Hash-based signatures. SLH-DSA and Winternitz rely only on hash functions, the most conservative security assumption there is. Error correction. Real qubits are noisy. Below a certain error rate, adding more qubits makes computations more reliable, and that's the threshold labs are now crossing.

Correction to an earlier post. We said a single post-quantum signature can't fit in a Solana transaction. That's true for ML-DSA and SLH-DSA. But Falcon-512, which Solana's validator clients are now testing, is about 666 bytes and fits. Falcon is now part of QS-RN-002.

The long-term goal: change how security is built, not just which algorithms it uses 🧵 Post-quantum cryptography is where we start. It's not where we stop. The same failures show up everywhere: single keys, unverified code, closed hardware, upgrades that come too late. Security that renews itself. Systems designed from day one to swap algorithms and raise parameters as threats change, without users rebuilding anything. Software you can check, not just trust. Formally verified critical code, reproducible builds and open audits as the default, not the exception. Keys that never exist whole. The same threshold design that protects a wallet can protect a company's signing keys, a cloud service or a personal identity. Hardware with open roots of trust. Devices whose security can be inspected and tested by anyone, not taken on faith. All of it as public infrastructure: open source, open standards, eventually stewarded by an independent foundation.

A promise about how we report progress: If a milestone slips, we'll post that it slipped, why, and the new target. No silent delays. No quiet roadmap edits.

What's coming from QuantSEC: the next days, weeks and months DAYS → All dev supply/buybacks will be locked. (Long term target of 2% each month) → Public GitHub organization opened → Research notes page live on the site, with a status for every item WEEKS → QS-RN-003: Threat model v1 published → QS-RN-001: Hybrid Ed25519 + ML-DSA signing spec released as a draft for public comment → Measurement harness for QS-RN-002 open sourced MONTHS → QS-RN-002: full results on post-quantum signature cost on Solana → Hybrid signing library alpha, open source → Audit firm selection for the library → Signing device prototype work begins → First quarterly transparency report Every item gets its own post when it ships, with links to the code, data or lock. If something slips, we'll say so and say why. A roadmap that only reports wins isn't worth following. All of this will be updated on the website as well as we continue to work and grow.

Hardware security lab: tools and test protocol Side-channel capture: ChipWhisperer platforms and oscilloscopes for power traces. Near-field EM probes for electromagnetic analysis. Leakage assessment: TVLA (Test Vector Leakage Assessment). Fixed vs random inputs, Welch's t-test, threshold |t| > 4.5 flags leakage. Fault injection: voltage and clock glitching, with every glitch parameter logged and swept systematically. Entropy: raw output of the hardware RNG analyzed with NIST's SP 800-90B assessment tool, plus continuous on-device health tests. Secure element: certified to Common Criteria EAL5+ or higher. Keys generated on-chip and never exported. Protocol: every device revision runs the full battery. Any failure blocks the next stage. Results published per revision.

Verification and testing stack 🧵 Known-answer tests: official NIST ACVP vectors for every ML-KEM, ML-DSA and SLH-DSA parameter set we ship. 100% must pass. Differential testing: our outputs compared against liboqs on randomized inputs. Any mismatch is a bug until proven otherwise. Fuzzing: cargo-fuzz and AFL++ on all parsers and decoders. Trident for Solana program instruction fuzzing. Property-based tests: proptest for encoding, serialization and arithmetic invariants. Undefined behavior: Miri on all unsafe code paths. Constant time: dudect-style statistical timing tests and Valgrind-based secret tracking on key-handling code. Formal verification: Kani model checking for critical Rust functions, and formal specification of vault state transitions. External audit before any release that holds user funds. Findings published.

Methodology for QS-RN-002: measuring post-quantum signature cost on Solana 🧵 Question: what does post-quantum spend authorization cost on Solana, per scheme and per design? Schemes: Ed25519 (baseline), Winternitz one-time signatures, SLH-DSA, ML-DSA-44 and ML-DSA-65. Designs: single-transaction verification where size allows, multi-transaction chunked verification via account buffers, and hybrid Ed25519 + PQ authorization. Metrics: transaction bytes, compute units, number of transactions, rent-exempt storage, total fees, end-to-end latency. Tooling: Mollusk and LiteSVM for deterministic compute-unit measurement, then devnet runs to confirm under real network conditions. Controls: fixed program versions, fixed inputs, repeated runs, median and worst case reported. Output: raw data, harness code and a written analysis, published together so anyone can rerun it.

QuantSEC software stack. What we build with, and why Language: Rust. Memory safety by default. Any unsafe block requires a written justification and a second reviewer. Post-quantum primitives: audited Rust implementations of ML-KEM (FIPS 203) and ML-DSA (FIPS 204). liboqs from the Open Quantum Safe project serves as an independent reference. Hash-based signatures: Winternitz and SLH-DSA (FIPS 205) constructions using SHA-256 and Keccak, which Solana exposes as native syscalls. On-chain programs: Rust, using Anchor for prototypes and Pinocchio where compute efficiency matters. Builds: reproducible and verifiable with solana-verify, so anyone can confirm deployed bytecode matches published source. Dependencies: pinned versions, cargo-audit and cargo-deny in CI. No unreviewed crates in key-handling code.

QuantSEC software stack. What we build with, and why Language: Rust. Memory safety by default. Any unsafe block requires a written justification and a second reviewer. Post-quantum primitives: audited Rust implementations of ML-KEM (FIPS 203) and ML-DSA (FIPS 204). liboqs from the Open Quantum Safe project serves as an independent reference. Hash-based signatures: Winternitz and SLH-DSA (FIPS 205) constructions using SHA-256 and Keccak, which Solana exposes as native syscalls. On-chain programs: Rust, using Anchor for prototypes and Pinocchio where compute efficiency matters. Builds: reproducible and verifiable with solana-verify, so anyone can confirm deployed bytecode matches published source. Dependencies: pinned versions, cargo-audit and cargo-deny in CI. No unreviewed crates in key-handling code.

Why quantum security will matter to crypto for decades, not just one cycle Crypto's whole promise is ownership by cryptography. Your key, your coins. If signatures can be forged, that promise breaks. Institutions already know it. Some Bitcoin ETF filings now list quantum computing as a risk factor. Custody, treasuries and funds will demand an answer. Chains upgrade slowly. Consensus, wallets, exchanges and custodians all have to move together. Past upgrades took years of coordination. Some funds may never move. Lost keys and dormant wallets can't migrate themselves, and every chain will face hard questions about them. And security doesn't end at one upgrade. Attacks improve, parameters age, new standards arrive. It's a permanent job. The chains that prepare early will be the ones people trust with real value for the next 20 years.

Harvest now, decrypt later isn't just about wallets. Medical records. Legal files. Trade secrets. Government cables. Anything that must stay secret for 20 years and is encrypted with today's methods is already at risk.

The scariest quantum attack isn't stealing money. It's forging a software update. Signatures are how your phone, laptop and car know new code is genuine. Break the signature, and malware arrives looking official.

This isn't speculation. The biggest institutions in tech and security are already moving 2024: NIST published the first official post-quantum cryptography standards. Chrome and other major browsers now use hybrid post-quantum key exchange for HTTPS connections. Signal and Apple's iMessage have added post-quantum protection to messaging. NIST's draft transition plan proposes phasing out RSA and elliptic curves in sensitive systems by 2035. Browsers, messengers and governments are migrating. Most of crypto hasn't started. That's the gap we work in.

Quantum security isn't a crypto problem. It's an everything problem Every time you see the padlock in your browser, public-key cryptography is setting up that connection. Card payments, bank transfers and online banking logins depend on it. So do the messages you send, the updates your phone installs, the chip in your passport and the firmware in your car. Power grids, hospitals, satellites and government systems use the same building blocks. Most of it runs on RSA or elliptic curves. The same math a large enough quantum computer would break. Blockchains are just where it shows up first, because the keys are public and the money moves directly.

What we're actually trying to build Security that renews itself. Algorithms with replacement plans, parameters that strengthen over time, upgrades that never require moving your funds. Keys that never exist in one place. Split across devices from the moment they're created, so there's nothing whole to steal. Funds that no elliptic-curve key controls. Vaults on Solana governed by program rules and quantum-safe proofs. Hardware that keeps secrets under attack. Signing devices that survive power analysis, fault injection and tampering, tested in our own lab first. All of it open source and audited, so anyone, on any chain, can check it and build on it. The goal isn't a product that's secure today. It's a system that stays secure for decades.

What happens to crypto the day elliptic curves break Every public key ever exposed on-chain becomes a door. Not some wallets. Every wallet whose key is visible, on every chain that uses ECC. It won't be announced. The first sign may just be old wallets emptying, blamed on bad opsec until the pattern is undeniable. Blockchains are permanent records. Keys posted in 2015 are still there. Nothing published on-chain can be taken back. Encrypted data has the same problem. Anything recorded today under classical encryption can be stored and opened later. Moving trillions of dollars of assets to new cryptography could be the largest security migration crypto has ever attempted. It can't start on the day it's needed. That's the work. Build the tools, test them in public, and have them ready before anyone has to use them. qsec.business

PDAs remove the private key. They don't remove risk. They move it. Here's where it goes 🧵 Into the code. If the program forgets to check who's allowed to withdraw, anyone can. Most Solana exploits have been missing checks like this, not broken cryptography. Into the upgrade key. Most programs can be upgraded by one Ed25519 key. That key is a single point of failure, and quantum-vulnerable. It must be removed or put behind threshold control and a time delay. Into the authorization rule. If the vault releases funds whenever a normal Ed25519 signer approves, a quantum attacker just forges that signer. The rule itself has to require a quantum-safe proof. Into the derivation. Programs must use the canonical address for each set of seeds, so attackers can't create look-alike vaults. Our checklist for every vault: immutable or threshold-governed program, quantum-safe authorization, canonical derivation, full audit. Miss one and the vault is only as strong as that gap.

What a Solana PDA actually is, and why it matters for quantum security A normal Solana address is an Ed25519 public key. Somewhere, a private key exists for it. Whoever holds that key controls the funds. A Program Derived Address is different. It's made by hashing a program's ID with some chosen inputs ("seeds"), then picking a result that is deliberately off the Ed25519 curve. Off the curve means no private key exists for it. Not hidden, not stored somewhere safe. It mathematically doesn't exist. So who controls a PDA? Only the program it was derived from. The program can authorize actions for that address, and nothing else can. That changes the security question. You stop asking "who has the key?" and start asking "what rules does the program enforce?" For quantum security that's the opening: no elliptic-curve key means nothing for Shor's algorithm to reverse. The rules decide, and the rules can require quantum-safe proofs.