Skip to content

Post-quantum key support in Kubo #11281

Description

@lidel

Filling because I could not find any meta-issue about this

Google published a threat model for post-quantum cryptography with a 2029 migration deadline.

IIUC the near-term risk is store-now-decrypt-later (SNDL): adversaries capturing encrypted traffic today for future decryption. This makes upgrading connection-layer forward secrecy urgent even before quantum computers exist.

NIST has finalized three post-quantum standards relevant to Kubo dependencies (libp2p and IPNS):

Algorithm Role Standard
ML-KEM Key encapsulation FIPS 203
ML-DSA Digital signatures FIPS 204
SLH-DSA Hash-based signatures FIPS 205

Multicodec code points for all three are registered or in review:

Ongoing spec and implementation discussions:

The goal is not to change the default key type away from Ed25519; that is a separate decision.

The goal is working, opt-in PQ support well ahead of any forced migration. Large public and private swarms need multi-year upgrade lead time before a new key type can be broadly relied upon. Starting late means the option to migrate gracefully disappears.

What needs to happen:

  • libp2p
  • IPNS
    • IPIP to decouple from libp2p and use key codes directly, without libp2p-key protobuf wrapper?
      • use PKIX and PKCS#8 "container" rather than libp2p-key?
      • when signing, use IPNS-specific ctx
    • Boxo support in boxo/gateway and boxo/ipns and boxo/namesys
    • Kubo support in ipfs name commands
  • IPFS
    • Have HTTP-only Kubo mode with identities, routing and retrieval using RFC envelopes and HTTP signatures (RFC 9421) instead of libp2p-key-based TLS tunnel/stack

Kubo does not need to wait for libp2p to fix IPNS, we should decouple anyway.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Medium: Good to have, but can wait until someone steps upneed/analysisNeeds further analysis before proceedingneed/community-inputNeeds input from the wider communityneed/maintainers-inputNeeds input from the current maintainer(s)status/blockedUnable to be worked further until needs are met

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions