Proof, not a promise
We sign and encrypt in post-quantum with our own sovereign engine. Here, you don't take our word for it: you test it yourself, live.
What this is about
Quantum computers will one day break the cryptography that protects our data, signatures and communications today. What is encrypted now can already be captured and stored, to be decrypted later. The countermeasure exists: quantum-resistant algorithms, standardised by NIST in 2024.
Our quaric-pqc engine implements these algorithms at the highest security level deployable today, with no external dependency. The two demonstrations below run for real on our server, every time you click.
Proving authenticity
Write a message. Our server signs it with a post-quantum key, then verifies the signature in front of you. Now change a single character: the signature becomes invalid. That is what unforgeable means.
Sharing a secret, safe from the quantum
ML-KEM does not exchange a text: it establishes a secret session key between two parties. The sender builds a capsule with the public key, the recipient opens it with their private key, and both obtain exactly the same key. Click to watch it happen.
Verify a signature, yours or someone else's
Paste a public key, the original message and the signature to check. Our tool answers a single question: does this signature truly match this message and this key?
We are not a certificate authority. We do not tell you who owns the key: we only confirm or deny the cryptographic consistency between the key, the message and the signature.
Understanding
SLH-DSA, the signature
SLH-DSA (FIPS 205) signs and proves authenticity. It relies solely on hash functions, a mathematical foundation considered the most robust against the quantum. Its trade-off: a large signature (close to 30,000 bytes), which illustrates why post-quantum is more demanding than classical cryptography.
ML-KEM, the encryption
ML-KEM (FIPS 203) establishes a shared, quantum-resistant session key. It is a key encapsulation mechanism: it does not encrypt the data directly, it secures the key that will then be used for symmetric encryption.
SHA3-256, the fingerprint
SHA3-256 produces a unique, unforgeable fingerprint of a piece of content. The slightest change in the data entirely changes the fingerprint. This is what seals integrity, from the kernel to the smallest package.
Why NIST level 5, and not higher
NIST ranks security in five categories. Category 5, equivalent to AES-256, is the highest. We place ourselves there: it is the maximum that can actually be deployed today in real-world systems and networks.
Research is exploring even higher security margins, but they remain experimental: key and signature sizes become too heavy for current network protocols. Claiming a "maximum level" you cannot run under real conditions would be meaningless. We hold the highest level that actually works.
Verify it yourself
A proof is only one if you can reproduce it without us. Download the demonstration public key and verify any signature on this page, from your own machine.
Command-line verification
With our quaric-pqc tool (or any FIPS 205-compliant tool), verification fits in a single command:
quaric-pqc verify demo-sig.pub message.txt message.sig
# exit 0 = valid signature
# exit 1 = invalid signature
Sovereign end to end
quaric-pqc is compiled from our own sources, with no OpenSSL or any third-party library, no network and no telemetry. Its compliance is proven against NIST's official test vectors. This is the same methodology we apply from the language to the OS: never depend on a foundation we do not control.
Does the demo really sign live?
Yes. On each click, our server runs the quaric-pqc binary, which actually signs or encrypts. Nothing is pre-recorded or simulated.
Is this demo's private key exposed?
This page uses a key pair dedicated to the demonstration, isolated and disposable. It has no connection to the authority that signs our production systems, whose private key never leaves our infrastructure.
Why is the signature so long?
Hash-based post-quantum signatures are large by nature (close to 30,000 bytes for SLH-DSA). That is the price of quantum resistance, and one of the reasons not everyone has deployed it yet.
Does this follow a standard?
Yes. SLH-DSA follows the FIPS 205 standard, ML-KEM the FIPS 203 standard, both published by NIST in 2024. Our implementation is verified against the official test vectors.
Why does it matter right now?
Because data encrypted today can be captured and kept to be decrypted the day the quantum is mature. Protecting now means anticipating that threat rather than enduring it.