EIPsInsight

Loading Experience

Preparing your insights...

Loading0%
PQTS2026-04-01_005

PQ Transaction Signatures #005

2026-04-01 425 transcript lines

Transcript

Ask about this call

Answered from this call's summary and transcript only.

AI-generated — verify against the recording.

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

Meeting chat23

  • 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

    https://t.me/+ozVdiAeQleBhZDg0

  • 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)

    https://eprint.iacr.org/2025/2203.pdf

  • Antonio Sanso

    Reacted to "https://eprint.iacr...." with 🙏

  • Conor Deegan

    Reacted to "https://eprint.iacr...." with 🙏

Key decisions

No key decisions recorded for this call.