🔔Post-Quantum Signatures: NIST's Second Wave In August 2024, NIST finalized its first PQC standards: ML-KEM (key exchange), ML-DSA, and SLH-DSA (signatures). A third signature, Falcon (FN-DSA, FIPS 206), is still in draft. Last week, NIST announced the nine candidates advancing to Round 3 of a parallel competition aimed at additional signature schemes, explicitly chosen to fill the gaps left by the first wave. Each of the standardized signatures comes with sharp trade-offs. None of them is naturally suited to threshold signing, and all have signatures that are large compared to ECDSA's 64 bytes. ➡️ SLH-DSA (SPHINCS+, hash-based) The most conservative choice: its security rests only on the collision resistance of a hash function. The price is enormous signatures (7–50 KB !!!). It is the safest pick for very long-lived signatures (firmware, archival, some blockchains such as QRL). ➡️ML-DSA (Dilithium, lattice-based). Compact and fast, while elegant, is younger than hash-based assumptions. It is becoming the default for TLS, PKI, and most non-blockchain ecosystems (~2.4 KB signatures). ➡️Falcon (FN-DSA, lattice-based). The smallest of the three (~666 B at NIST-I), which is why Algorand and Solana selected it. Its drawback: signing relies on floating-point arithmetic, making error-prone and side-channel-resistant/ constant-time implementations notoriously hard. Its FIPS 206 standard is still in draft. 🔍Most blockchains are leaning towards customized shorter versions of SLH-DSA. NIST is organizing a second wave of standardization. The goal is twofold: shrink signature sizes and diversify the underlying mathematics so a single cryptanalysis breakthrough cannot break everything. The nine Round 3 finalists span five families: 🔸 Isogeny: SQIsign 🔸 Lattice: HAWK 🔸 MPC-in-the-Head: MQOM, SDitH 🔸 Multivariate: MAYO, QR-UOV, SNOVA, UOV 🔸 Symmetric-based: FAEST Notably, no code-based scheme survived. Both Round 2 candidates were eliminated: LESS and CROSS were dropped because of 2 attacks 👉 Two candidates worth watching ⏩ SQIsign produces the smallest known post-quantum signatures by a wide margin: from 148B to 292B (depending on the level of security), with sub-130-byte public keys. That is the only PQC signature scheme today that even approaches the bandwidth profile of ECDSA, extremely attractive for blockchains, certificates, and firmware. The catch: isogeny-based cryptography is still young, signing is mathematically intricate, and side-channel hardening is an active research area. ⏩HAWK is essentially "Falcon without the floating-point." It is a lattice hash-and-sign scheme producing 555 B signatures at NIST-I (smaller than Falcon's 666 B) and can be implemented purely with integer arithmetic, a major engineering win. NIST has said the Round 3 review will last roughly two years and that any multivariate winners are unlikely to be standardized without yet another round. Realistically, the earliest a new signature standard will land alongside ML-DSA and SLH-DSA is 2028. The urgency to migrate has grown sharply, yet the current standards still have significant drawbacks, and this last-minute selection round, while necessary, collides head-on with the migration timeline.

This morning, THORChain was drained of roughly $10.8m Node operators have freezed the network for nearly 13 hours. The full analysis isn't out yet, but according to @jpthor, this could be a MPC exploit. ECDSA and TSS is hard. THORChain's vaults rely on TSS, a flavor of MPC where a quorum of nodes jointly produces a signature without ever reconstructing the private key. Clean for Schnorr or EdDSA; painful for ECDSA, which Bitcoin and Ethereum require. That's why we saw plenty of protocol attempts (Lindell17, GG18, GG20, CMP, CGGMP21, DKLS, KU23...), each patching flaws in the previous one. GG20 has a track record. THORChain's TSS uses GG20, on a fork of Binance's tss-lib. GG20 has shipped two well-publicized critical bugs: CVE-2023-33241 and TSSHOCK. CGGMP21, now cggmp24, are the latest protocols, but GG20 is still widely deployed. I often hear a misconception when I hear about MPC setup: "The key is split across many nodes, so any single co-signer doesn't really matter". In every published GG18/GG20 attack, one malicious or compromised co-signer is enough to extract everyone else's shard and reconstruct the full key. AI changes the threat model. Compromising a full software node, complex Go stack, exposed P2P, custom signing daemons, a churn protocol that admits new participants on a schedule, has always been difficult and acted as a barrier. With LLM-driven vulnerability discovery and exploit synthesis, the bar to compromise one of N validators is dropping fast. Here, it's a plausible TSSHOCK-style playbook: - compromise one operator - wait for it to churn into an active Asgard vault - send malformed proofs during keygen or signing - reconstruct the key offline - sweep in a single transaction It's unclear yet if the attacker used a known-unpatched GG20 weakness, or a fresh cryptographic flaw. But, in all cases, MPC and TSS are not a substitute for hardening every co-signer. They sit on top of co-signers that must each be treated as critical infrastructure, hardware-isolated enclaves, minimally exposed, continuously audited, and running protocol with security proofs. While the investigation progresses, be careful in your interactions onchain. These TSS setup are used in various protocols.

So proud of the @ledger team for making clear signing on Ethereum a reality. They built in the open, brought together stakeholders across the ecosystem, and created the 7730 standard as a public good for Ethereum.

🚨 A new NPM supply chain attack is currently underway, specifically targeting the AI ecosystem, including packages related to Mistral AI, OpenSearch, Guardrails AI, and others. It hooks into Claude and VS Code environments to steal user credentials, including GitHub tokens. What makes this attack especially sneaky is its persistence mechanism. It deploys scripts that monitor whether the compromised GitHub token gets revoked. The moment revocation is detected, the malware retaliates by wiping the user’s home directory. This punitive behavior both disrupts remediation efforts and buys attackers more time to deepen the compromise. We are entering a new era where attackers are becoming dramatically more capable, and defending against them is growing more difficult every day.

Directionally, I agree with this take, but it lacks urgency. We don't know when, or even if, a CRQC will arrive. That's not the point. Cryptography exists to provide trust in our systems, and once that trust erodes, it has to be rebuilt. Rebuilding takes time. We shouldn't wait for a CRQC to act. The whole world is going to migrate, and NIST has already laid out a timeline. For Bitcoin, the problem is harder: we need social consensus. As a community, we need to agree on a migration plan. What's the new signature scheme? Do we deprecate ECDSA and Schnorr? What's the impact on block size and throughput? Soft fork or hard fork? What's the activation timeline? And critically: what happens to coins that don't migrate, including the millions of BTC sitting in addresses with exposed public keys, or Satoshi's? These are concrete questions we need to answer before the FUD builds and trust erodes. The main question shouldn't be "Is there a quantum computer capable of breaking Bitcoin out there?" Framing the debate solely through that lens is a recipe for disaster.

Drift Protocol, one of the leading perpetual DEXs on Solana, has been hacked for approximately $213M. This makes it the biggest hack of 2026 so far, and one of the largest ever on the Solana blockchain, right behind the Wormhole Bridge exploit of 2022. The full details of the attack are still unfolding, but from what I understand so far, the multisig controlling the protocol was compromised, potentially days or even weeks before the funds were actually drained. Either the attackers directly stole enough private keys to meet the multisig threshold, or, more likely, they compromised several machines belonging to multisig signers and tricked the operators into approving a malicious transaction. The signers may have believed they were signing a legitimate operation while unknowingly authorizing the drain. This modus operandi is similar to the Bybit hack last year, widely attributed to DPRK-linked actors. The pattern is becoming familiar: patient, sophisticated supply-chain-level compromise targeting the human and operational layer, not the smart contracts themselves. This is yet another wake-up call for the industry. We need to collectively raise the bar on security: - Better detection mechanisms at the network and endpoint level to catch compromised environments before they can be weaponized. - Secure key management with proper governance, hardware-backed signing, operational procedures that assume individual machines can be compromised. - Clear signing: ensuring that signers always have full, human-readable visibility into what they are actually approving. Ultimately, security is not just about code audits. It's about giving operators and users the right information at the right time, so they can make informed decisions about what they sign. Stay safe.