What's the impact for HWW, and Ledger in particular?
What does it mean for blockchains?
In particular block size, fees, throughput
What's the timeline? And what do we do for non-migrated coins?
Coins sitting on exposed public keys today
Charles Guillemet / CTO Ledger / @P3b7_ / 2026
Open with: "The debate around PQ is often: when will we have a CRQC? I think it's the wrong framing. We use cryptography to create trust. When that trust erodes, it's time to upgrade. And the trust is eroding now."
"As an ecosystem, we need to address three questions together." Read the three on screen.
"This is a conversation, not a lecture. Jump in at any time. Let's start with algorithms."
Spend ~3 minutes. Set the tone, then move on.
?
Main security properties of a hardware wallet?
"Let's start with algorithms. Signature algorithms are implemented inside Ledger devices. Before we talk about which PQ algorithm, let's talk about where they run."
Ask the group: "Do you know what the main security properties of a hardware wallet are?"
Let participants answer. They'll likely mention key storage, maybe signing. Wait for answers, acknowledge them.
Then advance to the next slide to complete and confirm.
Algorithms
Security Properties of a Hardware Wallet
Seed & key confidentiality
Seed is generated inside the SE with a high quality randomness source
Cryptography is implemented inside the SE so that keys don't have to leave the Secure Element
WYSIWYS
Strong link between the Display and what's happening inside the SE
Transaction parsing – clear signing
Attestation
The device is able to prove genuineness
It's possible to mount a Secure Channel with Ledger's HSM
Firmware protection & physical resistance
SCA, fault injection, glitching resistance
Code execution integrity
Complete with what participants missed. Make sure these land:
Key confidentiality: keys never leave the SE. Not encrypted, not wrapped. Confined.
WYSIWYS: the SE drives the trusted display. A compromised host can't alter what you see.
Genuineness: cryptographic attestation. Not a sticker. A signature.
Physical resistance: SCA, FI, glitching. Secure channel for firmware.
"All of these rely on cryptography running inside the Secure Element. PQ algorithms must run in the same place, under the same constraints."
Constraints
Hardware Constraints & PQ Implications
SE Chip
RAM
Flash
CPU
PQC Accel.
ST31H320
10 KB
320 KB
28 MHz
None
ST33J2M0
50 KB
2 MB
60 MHz
None
ST33K1M5
64 KB
1.5 MB
70 MHz
None
Next-gen
150 KB
4.5 MB
200 MHz
ML-DSA, Keccak
Signing performance (vs ECDSA = 1x)
ECDSA (HW)
1x
Baseline
ML-DSA (HW)
~3x
Next-gen
Falcon-512 (SW)
~20x
Current SE
ML-DSA (SW)
~50x
Current SE
SPHINCS+-128s (HW)
~60x
Next-gen
SPHINCS+-128s (SW)
~300x+
Current SE
What does this mean for PQ?
Falcon
Smallest sigs (666 B). But requires FP arithmetic. No FPU on SE. FP rounding exploitable for SCA/FI.
ML-DSA
NIST primary. 3.3 KB sigs. ~50x slower in SW, ~3x in HW. Pragmatic, not conservative. Module-LWE is young.
SPHINCS+
Hash-only security. Most conservative. 7.8 KB+ sigs. ~60x in HW, ~300x in SW. Slow and large.
Stateful (XMSS/LMS)
Conservative. But each sig burns a one-time key. Lose the state = stop signing forever. Another secret to back up. UX dead end.
Signature sizes (bytes)
ECDSA
72
72 B
Falcon-512
666
666 B
ML-DSA-65
3,309
3,309 B
SPHINCS+-128s
7,856
7,856 B
Your turn to explain. "Let me walk you through the main constraints of a hardware wallet and what it means for PQ."
Point to the SE specs table: "This is what we work with. 64 KB of RAM. 70 MHz. No PQ hardware acceleration on current chips."
"SW-only crypto means no hardware countermeasures against side-channel or fault injection. Every branch depending on secret data leaks. Masking, blinding must be reimplemented from scratch for each new primitive."
Walk through the performance chart: "ECDSA is our baseline. ML-DSA in SW: 50x slower. With HW accel on next-gen silicon: 3x. That's the difference."
Walk through the four scheme cards and signature sizes. For each: what's good, what's the catch.
Ask: "What does this mean for PQ implementation? Which of these can realistically run on a Secure Element?"
Ask: "Questions on the constraints or the algorithms?"
Spend ~10 minutes. Let the discussion breathe.
What we built
PQ-SCP: Post-Quantum Secure Channel
The secure channel protects firmware updates. If an adversary breaks it, they own every future firmware update. This is target #1 for PQ migration.
KEMTLS-inspired: KEM-only at runtime
3 KEM encapsulations, 0 signatures during handshake
"Now let me talk about what we actually built. The secure channel is the most urgent target. Harvest-now-decrypt-later makes this a real threat today, not when quantum arrives."
"Why KEM-only at runtime? In classical TLS, ECDH + ECDSA use the same ECC arithmetic. Cheap. In PQ, signatures and KEMs are different beasts. KEMTLS says: use KEMs for both key exchange and authentication. One primitive at runtime. Much cheaper on a Secure Element."
"X-Wing is our hybrid KEM: ML-KEM-768 + X25519. Belt and suspenders. Forward secrecy holds if either component survives."
"This is done. Running on current hardware. In software."
Ask: "How do you think about the transition? Devices in the field run classical SCP. What's the upgrade path?"
Spend ~5 minutes.
Challenges
Stateful Signatures: The SHRINCS Example
SHRINCS (Blockstream Research) is a clever hybrid: a compact stateful path for daily use, with a stateless SPHINCS+ fallback if state is lost. Let's look at how it works — and why statefulness remains a hard problem.
How SHRINCS works
Single public key, two signing paths
Compact path: unbalanced XMSS tree — 324 bytes for the 1st sig, +16 bytes each
Parallel signing, device cloning, firmware bugs — any of these can cause leaf reuse
Software wallet can check for reuse before broadcasting, but it's a mitigation, not a fix
Scale: one state per UTXO, address, account
Users have 100s of UTXOs, addresses, accounts — that's as many states to maintain
They won't fit into the device — requires Merkle trees of monotonic counters
Breaks device portability and independent recovery
The fallback path is expensive
SPHINCS+ signatures are ~5.7 kB — 90x larger than today's Schnorr
Signing on a SE: minutes in software, seconds even with HW acceleration
Compact path signature size
Schnorr (today)
64 B
SHRINCS (1st sig)
324 B
SHRINCS (16th sig)
580 B
SHRINCS fallback
~5.7 kB
The Bitcoin vs Ledger gap
SHRINCS is designed for Bitcoin's "don't reuse addresses" culture. One key, one or a few signatures. That's a great fit.
Users have hundreds of UTXOs, addresses, accounts — each needs its own monotonic counter. They won't fit on the device, so you need Merkle trees of counters. This breaks device portability and independent recovery.
Bottom line
SHRINCS is a smart design for its target use case. But for a multi-chain hardware wallet, stateful signatures turn every backup, every restore, every firmware update into a potential security incident. The operational complexity doesn't match the user model.
"Let me talk about stateful signatures using SHRINCS as an example. It's a very clever design from Blockstream Research."
"The idea: one public key, two signing paths. A compact stateful path — 324 bytes for the first signature, growing 16 bytes each time — and a stateless SPHINCS+ fallback if you lose the device."
"It's built on SHA-256 only. The most conservative assumption you can make. And it's designed for dedicated signing devices where state never leaves the hardware."
"For Bitcoin, where you don't reuse addresses and a key signs once or twice, this is elegant. The state problem is manageable."
"But in practice? Users have hundreds of UTXOs, addresses, accounts. Each one needs its own monotonic counter. They won't fit on the device — you end up needing Merkle trees of counters. And that breaks device portability and independent recovery."
"And the failure mode: parallel signing, device cloning, stale backup restore — any of these causes leaf reuse, which breaks the security. The fallback exists, but it's ~5.7 kB signatures and minutes of compute on a SE."
"SHRINCS is a great design for its target. But stateful signatures don't match the operational model of a universal hardware wallet."
?
Chains will migrate at some point.
What's your take on coins that are not migrated?
Coins sitting on exposed public keys. Lost wallets. Satoshi's coins. What happens to them?
"Chains will migrate at some point. New address types, new opcodes. But what about the coins that don't move?"
Open the floor. Let the group discuss freely. Wait for answers.
Then advance to the next slide to show the full picture and discussion points.
Open discussion
Blockchains, Migration & Non-Migrated Coins
Block size impact
ML-DSA-65: 3,309 B vs ECDSA 72 B = 46x per signature
Bitcoin: ~2,500 sigs per block today. With ML-DSA?
L1 fees multiply. Throughput drops.
Which scheme will chains pick?
Ethereum has started exploring PQ migration paths
Bitcoin: no consensus mechanism yet for PQ sig type
New address formats, new opcodes, soft fork or hard fork?
Non-migrated coins
Coins on reused addresses: public key is exposed on-chain
P2PKH with exposed pubkey: quantum-vulnerable today (HNDL)
Satoshi's coins: ~1M BTC on exposed keys
The migration dilemma
Users must actively move funds to a new PQ address format. But many won't. Lost keys, dead wallets, forgotten coins. What happens to the coins that don't move?
Exposed public keys
Any address that has sent a transaction has its public key on-chain. A CRQC can derive the private key from the public key. No transaction needed from the victim.
Possible approaches
Soft-fork new PQ address type (like SegWit). Freeze exposed keys after deadline? Require proof-of-knowledge to spend? Each has trade-offs. None are clean.
Stay safe. Stay honest about your trust assumptions.
Complete the discussion with what participants may have missed.
"ML-DSA-65 is 46x larger than ECDSA. Think about what that does to Bitcoin blocks. Fees. Throughput. This isn't theoretical, it's economic."
Points to surface: exposed public keys (any address that ever sent a TX), Satoshi's coins (~1M BTC), possible approaches (freeze? deadline? proof-of-knowledge?).
"There is no consensus on this. The ecosystem needs to start having this conversation."
Wrap-up (last 1-2 min): "Three things to take away. One: PQ on constrained hardware is fundamentally different from PQ on a server. Two: the secure channel is done. Three: blockchain PQ signatures and non-migrated coins are open problems the ecosystem must solve together."
Wrap up promptly when the rotation is called. Let the group go immediately.