Post-quantum key support in Kubo

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:

• multiformats/multicodec#358
• multiformats/multicodec#392
• multiformats/multicodec#394
• multiformats/multicodec#399

Ongoing spec and implementation discussions:

• Browser Industry (AKA The Google Chrome Monopoly):
  • https://chromestatus.com/feature/5198951632470016
  • https://wicg.github.io/webcrypto-modern-algos/
• ipfs, libp2p-key and things that enable decoupling from libp2p-key
  • libp2p/specs#710 RFC-0004
  • https://github.com/libp2p/specs/pull/711
  • https://github.com/multiformats/multicodec/pull/400
  • https://github.com/multiformats/multicodec/pull/403

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
  • libp2p/specs#710
  • new key type in go-libp2p
  • Cross-implementation interop tests (Go / JS) exist
  • go-libp2p release with new key
  • Kubo support in ipfs key commands
• 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.