PQ Transaction Signatures #005
Transcript
- Stefano Gogioso
It's a kind-of commutativity issue, isn't it in the end
- Antonio Sanso
Reacted to "It's a kind-of commu..." with 👍
- Matteo Vena
Can you drop your tg Connor?
- Matteo Vena
Conor*
- Conor Deegan
Reacted to "Can you drop your tg..." with 👍
- Stefano Gogioso
Additionally, a smaller portion of the overall 64KB of RAM is available for heap allocations in apps (at least in our experiments).
- Conor Deegan
Reacted to "Additionally, a smal..." with 👍
- alan xu
Where’s the tg group for PQTS?
- Antonio Sanso
- alan xu
Reacted to "https://t.me/+ozVdiA..." with 👍
- Conor Deegan
Given the tradeoffs mentioned how do we as a group work together such that signers, verifiers, clients, etc work together to find a middle ground that will work across layers of the stack? “Pick your poison”
- Antonio Sanso
Replying to "Given the tradeoffs ..." Good question…
- Conor Deegan
Replying to "Given the tradeoffs ..." What is good on one side is bad for the other it feels
- alan xu
Will Etheream choose lattice based or hash based PQ scheme?
- Stefano Gogioso
Reacted to "Given the tradeoffs ..." with 👍
- Thomas Coratger
Répondre à "Will Etheream choo..." Still an open question I think but hash based assumptions are always more conservative
- alan xu
Reacted to "Still an open questi..." with 👍
- Conor Deegan
Reacted to "Still an open questi..." with 👍
- Stefano Gogioso
We are specifically interested in MPC-in-the-Head support, would be good to have a touch point on that.
- Conor Deegan
Reacted to "We are specifically ..." with ➕
- Alain MAGAZIN (LEDGER)
- Antonio Sanso
Reacted to "https://eprint.iacr...." with 🙏
- Conor Deegan
Reacted to "https://eprint.iacr...." with 🙏
Call summary
Highlights
- Algorithm Viability:
- ·ML-DSA: confirmed next-gen, likely legacy devices (with side-channel protections TBD) - 00:41:28
- ·Falcon: feasible next-gen, uncertain legacy due to floating-point masking complexity - 00:42:45
- ·SLH-DSA: unlikely for signing on any current/next-gen hardware - 00:43:15
- Bip32 Key Derivation:
- ·First BIP32 non-hardened derivation for lattice-based PQ (RaccoonG) - 00:07:03
- ·Gaussian distributions enable unlinkable child keys up to ~500k depth - 00:12:49
- ·Hash-based signatures cannot support extended public keys (non-hardened paths) - 00:21:30
- Next Generation Hardware:
- ·Next-gen SE: 158KB RAM, Keccak IP, ML-KEM/ML-DSA hardware acceleration - 00:40:17
- ·No planned HW acceleration for Falcon or SLH-DSA - 00:40:58
- Implementation Approaches:
- ·Ephemeral mode compatible with lattice HD wallets for stateless reusable keys - 00:18:29
- ·Few-time signatures (Winternitz) viable for ephemeral use cases - 00:22:02
- ·Stateful hash schemes with stateless fallback under Bitcoin community consideration - 00:51:51
- Hardware Wallet Constraints:
- ·Current Ledger SE: 64KB RAM, 70MHz - tight for PQ schemes - 00:31:41
- ·Falcon-512 signing barely fits with OS overhead; Falcon-1024 doesn't run - 00:34:23
- ·ML-DSA runs with low-RAM implementation but 5+ second signing time - 00:36:50
- ·SLH-DSA signing: 6 minutes at 128-bit security - unacceptable UX - 00:38:42
Action Items
- •Connor (Project 11), Matteo, Stefano - Offline discussion on BIP85 + few-time signatures for ephemeral keys - 00:23:33
- •Ledger team - Begin side-channel countermeasure work for ML-DSA and Falcon - 00:45:01
Key decisions
AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.