Skip to main content

Package overview

All cryptographic signature loaders share one interface: keypair(), sign(), verify(), and buffer_to_string().

In the browser, keypair() and sign() throw. Use loadOpfsSkWallet() (WebAuthn userVerification: required, prf: {} at registration, eval on get, AES-GCM ciphertext in OPFS). Node and server REST load*() loaders are unchanged. verify() and ML-KEM are not gated.

Public loaders​

import {
  // KEM
  loadMlKem512,
  loadMlKem768,
  loadMlKem1024,
  // Signatures
  loadFnDsa512,
  loadFnDsa1024,
  loadMlDsa3,
  loadMlDsa5,
  loadSqisignLvl1,
  loadSqisignLvl3,
  loadSqisignLvl5,
  loadSlhDsa128,
  loadSlhDsa192,
  loadSlhDsa256,
  // Browser-accelerated SQIsign
  loadSqisignLvl1WebGpu,
  loadSqisignLvl3WebGpu,
  loadSqisignLvl5WebGpu,
  getSqisignWebGpuSupport,
  setSqisignAccelWorkerUrl,
  // Browser OPFS encrypted-sk wallet (COI required)
  loadOpfsSkWallet,
  setOpfsSkWorkerUrl,
} from "quantum-resistant-rustykey";

Specification notice (SQIsign identifiers)​

COSE/JOSE algorithm IDs (-61, -62, -63) and strings (SQIsign-L1, SQIsign-L3, SQIsign-L5) follow the active cose-sqisign Internet-Draft. They are provisional — not final IANA assignments. Use them for interop testing and R&D.

Why SQIsign matters for WebAuthn​

Many FIDO2 / CTAP2 authenticators use a ~1024-byte buffer. Dilithium-class signatures (~2.4 KB) and Falcon-1024 do not fit. SQIsign signatures (~200 bytes class) are currently the practical PQC option that fits with metadata.

Credits​

  • NIST (ML-KEM, ML-DSA, SLH-DSA / FN-DSA lineage)
  • SQIsign team — official C at SQISign/the-sqisign
  • ML-KEM packaging approach adapted from mlkem-wasm

Funding​

Supported by University of Quantum Science, RustyKey®, Customers' Yachts® Advisors, and BuzzyBee®.