Quantum Vault
Sovereign post-quantum tokens for the Q-Day era
Beta · v0.1.0 · MIT licensed
Sovereign post-quantum tokens for the Q-Day era
Issue, store, and validate post-quantum cryptographic tokens using NIST-standardised algorithms. Designed for sovereign identity, signed credentials, and quantum-resistant secrets management — ready before Q-Day breaks today's public-key cryptography.
Key capabilities
- Post-quantum tokens — CRYSTALS-Kyber + Dilithium
- Sovereign deployment — self-hosted, no third-party trust
- Quantum-resistant ahead of Q-Day
- Token issuance, validation, and rotation primitives
- Built on the NIST PQC standards (FIPS 203 / 204)
Resources & quick links
What is Quantum Vault?
Quantum Vault issues, validates, and rotates cryptographic tokens using NIST-standardised post-quantum algorithms — CRYSTALS-Kyber (ML-KEM / FIPS 203) for key encapsulation and CRYSTALS-Dilithium (ML-DSA / FIPS 204) for signatures. It is built for teams that want their identity and secrets infrastructure to be resistant to a future quantum adversary.
It is in Beta, and 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 Dilithium and, where confidentiality is needed, wraps secrets using Kyber key encapsulation — both NIST-standardised post-quantum schemes.
- Validate. Services verify token signatures locally against the issuer's public key, so validation does not depend on an external authority being online.
- 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 NIST PQC standards (FIPS 203 / 204).
Limitations & honest trade-offs
- Beta and security-sensitive: evaluate carefully and review against your threat model before production use.
- Post-quantum keys and signatures are larger than classical equivalents, 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-Kyber (ML-KEM, FIPS 203) for key encapsulation and CRYSTALS-Dilithium (ML-DSA, FIPS 204) for signatures — both standardised by NIST.
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.
Tekivex · open-source enterprise developer tools · MIT licensed · Products · Use Cases · About · TekiVex UI