Quantum Vault
Sovereign post-quantum tokens for the Q-Day era
Beta · v0.1.0 · Free for commercial use
Sovereign post-quantum tokens for the Q-Day era
Issue, validate, and rotate post-quantum cryptographic tokens using NIST-standardised ML-DSA-87 (Dilithium-5 / FIPS 204) signatures with XChaCha20-Poly1305 encrypted payloads. Designed for sovereign identity, signed credentials, and quantum-resistant secrets management — ready before Q-Day breaks today's public-key cryptography. Ships on npm as @sigvault/sdk.
Key capabilities
- Post-quantum signatures — CRYSTALS-Dilithium (ML-DSA-87, FIPS 204)
- Encrypted payloads — XChaCha20-Poly1305 authenticated encryption
- Replay protection — stateful HYDRA mutation chain
- Sovereign deployment — self-hosted, no third-party trust
- Token issuance, validation, and rotation primitives — pure JS (@sigvault/sdk)
Resources & quick links
What is Quantum Vault?
Quantum Vault issues, validates, and rotates cryptographic tokens using NIST-standardised post-quantum cryptography — CRYSTALS-Dilithium (ML-DSA-87 / FIPS 204) for signatures, with payload confidentiality provided by XChaCha20-Poly1305 authenticated encryption. It is built for teams that want their identity and secrets infrastructure to be resistant to a future quantum adversary. On npm it ships as @sigvault/sdk.
It is deliberately sovereign: you self-host it, so there is no third-party trust dependency for issuing or validating tokens. The threat it addresses is "harvest now, decrypt later" — data captured today that a quantum computer could break once Q-Day arrives.
How it works
- Issue. Quantum Vault generates tokens signed with ML-DSA-87 (Dilithium-5) and encrypts the payload with XChaCha20-Poly1305, so claims are confidential rather than merely base64-encoded as in a JWT.
- Validate. Services verify token signatures locally against the issuer's public (verifying) key, so validation does not depend on an external authority being online. A stateful HYDRA mutation chain provides replay protection.
- Rotate. Issuance, validation, and rotation primitives let you roll keys and expire tokens on a schedule, which is essential for long-lived credentials in a post-quantum posture.
When to use Quantum Vault
- Sovereign identity and signed-credential systems that must outlive current public-key cryptography.
- Long-lived secrets where "harvest now, decrypt later" is a realistic threat.
- Air-gapped or self-hosted environments that cannot depend on a third-party token service.
- Organisations preparing migration plans for the NIST PQC signature standard (ML-DSA / FIPS 204).
Limitations & honest trade-offs
- Security-sensitive: evaluate carefully and review against your threat model before production use.
- Post-quantum signatures are larger than classical equivalents (ML-DSA-87 signatures are roughly 4,627 bytes), which has bandwidth and storage implications worth measuring.
- It is self-hosted by design — you operate the deployment and own key management.
Frequently asked questions
Why post-quantum now, before quantum computers can break RSA?
Because of "harvest now, decrypt later" — encrypted data captured today can be stored and broken once a capable quantum computer exists. Anything that must stay secret for years should migrate ahead of Q-Day.
Which algorithms does it use?
CRYSTALS-Dilithium (ML-DSA-87, FIPS 204) for signatures, standardised by NIST, plus XChaCha20-Poly1305 for authenticated payload encryption and a HYDRA mutation chain for replay protection.
Is it hosted or self-managed?
Self-managed. Quantum Vault is sovereign by design so there is no third-party trust dependency for issuing or validating tokens. On npm the package is @sigvault/sdk.
Tekivex · free developer tools · Free for commercial use · Products · Use Cases · About · TekiVex UI