WEBVTT Automatically timed original source text; AI narration; timing not manually listen-through verified.

00:00:00.000 --> 00:00:04.320
Breakout Session: Post Quantum Cryptography for Hardware Wallets.

00:00:04.500 --> 00:00:14.500
Notes from the breakout session led by Charles Guillemet at the Post-Quantum Bitcoin Workshop at Stanford, 28 August 2026, written by Localhost Research.

00:00:15.040 --> 00:00:16.820
This is an AI recording.

00:00:17.160 --> 00:00:22.200
Find the original text and more information on btctranscripts.com.

00:00:22.340 --> 00:00:23.760
Why act now

00:00:24.280 --> 00:00:38.120
The Bitcoin community's perspective on PQ has clearly evolved — not because a quantum computer is coming tomorrow, but because a non-zero probability creates fear, and if trust erodes, that must be addressed.

00:00:38.950 --> 00:00:49.910
Migration requires picking the algorithm and answering broader questions: What does it mean for blockchains (block size, etc.)? What's the timeline and execution plan?

00:00:50.440 --> 00:00:56.100
This session focuses mostly on the algorithm choice, given its impact on hardware wallets.

00:00:56.380 --> 00:00:58.560
How hardware wallets work today

00:00:59.020 --> 00:01:05.400
Core security property: seed/key confidentiality, generated with high entropy.

00:01:06.160 --> 00:01:15.290
Built on secure elements (smart card technology — effectively a small computer), with Ledger's operating system on top managing applications:

00:01:15.570 --> 00:01:18.090
Different coins → different applications

00:01:18.850 --> 00:01:22.710
Mono-threaded architecture; apps isolated from the OS

00:01:22.710 --> 00:01:27.470
Derivation path locks — the Bitcoin app can only derive Bitcoin keys

00:01:27.470 --> 00:01:35.170
"What you see is what you sign": the host is not trusted; the device's own screen makes that trust unnecessary.

00:01:36.940 --> 00:01:46.620
Attestation: genuine device proofs, firmware upgrades with strong guarantees of authenticity. ⚠️ The current secure channel is not post-quantum.

00:01:46.760 --> 00:01:48.000
The constraint problem

00:01:48.000 --> 00:01:58.520
Current secure elements are deliberately tiny: 10→64 KB RAM, 320 KB→1.5 MB flash, 28→70 MHz CPU.

00:01:58.820 --> 00:02:09.810
Hardware acceleration exists for AES, DES, and modular multiplication (RSA/EC) — nothing for PQ. PQ must be implemented in software on-device, with constrained performance.

00:02:10.130 --> 00:02:14.610
And they'll need to implement all the algorithms, because they support so many blockchains.

00:02:14.610 --> 00:02:15.780
Benchmarks

00:02:15.780 --> 00:02:18.120
Scheme: vs. ECDSA.

00:02:18.120 --> 00:02:20.980
Falcon: ~20× slower.

00:02:21.520 --> 00:02:26.060
Full SPHINCS (current SE): ~300× slower — ~7 minutes.

00:02:26.420 --> 00:02:32.800
Full SPHINCS (next-gen SE with PQ support): ~60× — several dozen seconds.

00:02:33.320 --> 00:02:35.460
SHRINCS: Completely acceptable performance.

00:02:35.840 --> 00:02:37.520
PQ secure channel work

00:02:37.860 --> 00:02:47.140
Ledger has designed a PQ upgrade and attestation protocol, KEM-TLS-inspired, with a proof written in Lean 4, currently being audited.

00:02:48.140 --> 00:02:54.800
No standard exists for PQ secure channels in embedded setups — they will share the standard they create.

00:02:55.300 --> 00:02:56.300
Discussion note

00:02:56.860 --> 00:03:01.860
On Trezor-style open-source secure elements: hard to compete with a well-resourced actor.