Built on public, peer-reviewed standards. QNSQY, a post-quantum cryptography tool, uses independently verifiable algorithms. No security through obscurity.
"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."
19,769 NIST ACVP vectors pass byte-for-byte against expected output, with zero failures, in the 2026-09-24 sweep. Replays ACVP-Server v1.1.0.43 (commit 975de31eb83d87) against the same open-source Rust crates QNSQY ships. Sweep wall-clock: 1,014.23 s (one machine).
Out of 31,071 attempted, 3,018 of them post-quantum. 11,302 documented skips for vector classes we do not implement (e.g., bit-oriented hash messages, SP 800-56C two-step key derivation, Ed448, Curve448).
Every non-skipped vector matches the expected output. No discrepancies, no waivers, no retries.
36 of 55 ACVP algorithm directories at 100% coverage of NIST vectors.
What this is NOT: FIPS 140-3 / CMVP certification, and not an external audit. This is reproducible test-vector evidence: NIST ACVP vectors replayed byte-for-byte against the open-source libraries compiled into the shipped qnsqy binary (it tests those libraries, not QNSQY's own code), plus internal end-to-end format tests. Anyone can reproduce it with the standalone harness v1.1 published on the Validation page; full source access for customers and auditors is available on request under NDA. CMVP is on the roadmap.
Earlier write-up (June 2026, ACVP-Server v1.1.0.42): NIST ACVP test sweep, 18,703 vectors and zero failures.
The ACVP sweep above checks valid-input correctness. Project Wycheproof checks the other half: that bad input is rejected. QNSQY runs Google's official Project Wycheproof v1 adversarial test vectors on every build; on the current C2SP files (2026-09-24 run) 4,884 vectors execute with zero failures. They exercise the reject paths that matter for security: tampered AES-GCM authentication tags, malleable Ed25519 signatures, malformed public keys, and twisted-curve points. The ML-KEM-512/768/1024 and ML-DSA-44/65/87 sets run through QNSQY's own key-exchange and signing code; the AES-256-GCM and XChaCha20-Poly1305 vectors test QNSQY's own AEAD code; the Ed25519, X25519, HKDF, HMAC, and IETF ChaCha20-Poly1305 vectors test the exact RustCrypto and dalek crate versions QNSQY ships. Like the ACVP replay, this is byte-for-byte test-vector replay, not a FIPS 140-3 or CMVP certification. CMVP is on the roadmap; no application has been submitted.
Quantum computers cost billions. You won't own one. But nation-states, intelligence agencies, and well-funded adversaries are building them. They're not waiting for you to catch up.
QNSQY exists to close this gap. Quantum-resistant encryption that runs on your existing hardware. No billion-dollar lab required. Protection against threats most people don't even know exist yet.
Factors integers in polynomial time. On a large enough quantum computer, published estimates put RSA-2048 at hours to days, not billions of years.
Quadratic speedup on search. AES-256 becomes AES-128 equivalent. Still secure.
Classical computing hit a wall. Quantum is climbing over it. The attackers aren't waiting. Neither should you.
QNSQY uses a defense-in-depth architecture with hybrid cryptography. Both post-quantum and classical algorithms must be broken to compromise your data, whether it is a single document, a database column, a backup stream, or a cold-storage archive.
Scroll horizontally to view full diagram
Attacker must break BOTH algorithms to decrypt
Breaks X25519 instantly. But ML-KEM remains secure. Your files stay protected.
Cryptanalysis discovers weakness. X25519 still protects. No silent failure.
Double protection. Defense in depth. The gold standard for post-quantum migration.
QNSQY uses only public, peer-reviewed cryptographic standards. These algorithms have been scrutinized by the global security community and adopted by governments, enterprises, and security-conscious organizations worldwide.
Winner of the Password Hashing Competition. OWASP recommended. Memory-hard design defeats GPU and ASIC attacks.
Industry standard authenticated encryption. Hardware-accelerated on modern CPUs. 256-bit keys for maximum security.
All tiers. Extended nonces. Excellent performance without AES hardware. Used by WireGuard, Signal.
AND construction: attacker must break BOTH. All tiers use hybrid: Free=ML-KEM-512 + X25519, Pro=ML-KEM-768/1024 + X25519, Business adds HQC + X25519. NIST FIPS 203.
Pro+. AND construction: both ML-DSA (FIPS 204) + Ed25519 must verify. Defense in depth.
Pro+. NIST FIPS 205. Alternative PQ signature scheme with different security assumptions.
Business only. FIPS 206 not yet published (pre-standard Falcon implementation). NTRU-lattice signatures with compact output (~666 bytes for FN-DSA-512). Standalone or hybrid with Ed25519.
Business only. NIST Round 4 selection (March 2025). Error-correcting code KEM providing algorithm diversity from lattice-based ML-KEM. Three security levels.
Business only. Leighton-Micali hash-based signatures (RFC 8554). Security rests only on the hash function (second-preimage resistance of SHA-256), with no algebraic assumptions. Stateful key management required.
Modern cryptographic hash. Faster than SHA-256. Merkle tree structure enables streaming and partial verification.
"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."Kerckhoffs's Principle Cryptography 101, Auguste Kerckhoffs, 1883
This is why we publish our architecture openly. Security through obscurity is not security. Every algorithm we use is a public, peer-reviewed standard.
All tiers use hybrid KEM (ML-KEM + X25519) with AES-256-GCM symmetric encryption. Pro+ adds hybrid signatures (ML-DSA + Ed25519). AND construction ensures attacker must break BOTH algorithms. All NIST standardized (FIPS 203/204/205).
Every encryption uses fresh random keys, so a key exposed for one file opens no other file. A leaked password or private key still opens every file protected with it.
AES-256-GCM and XChaCha20-Poly1305 provide both confidentiality and integrity. If anyone modifies an encrypted file, even a single bit, decryption will fail. No silent corruption.
Argon2id requires significant memory to compute. This makes password cracking with GPUs and ASICs extremely expensive. A weak password becomes much harder to brute-force.
QNSQY never sees your password, your files, or your keys. All cryptography runs locally on your device. Our account server holds only account, sign-in and billing records, never file contents, passwords or keys.
On the Linux command line, after the short billing check, a kernel filter (seccomp-bpf) blocks every network call before any cryptographic work, so the operation itself cannot reach the internet.
Platform Note: There is no macOS build yet. On Windows, when run as administrator, QNSQY adds an outbound Windows Firewall rule that blocks itself for the duration of each cryptographic operation (after the licence check) and removes it afterwards; as a standard user no block is enforced and QNSQY warns. For air-gapped security on Windows, physically disconnect from the network. The desktop app's own window process keeps network access (it needs sockets for the display); its cryptographic operations run in separate command-line processes, which on Linux are under the network lock.
QNSQY is designed to protect against these specific threats:
Adversaries collecting encrypted data today to decrypt with future quantum computers.
Password guessing using GPUs, ASICs, or cloud computing resources.
Modification of encrypted data at rest, whether accidental or malicious.
Your files and keys are never sent to a cloud. Optional remote backup uploads only data already encrypted on your device. Our account and billing service runs on Cloudflare and holds account, sign-in and billing records only.
We cannot hand over your files, passwords or keys: they never leave your device. We do hold account, sign-in and purchase records.
seccomp-bpf blocks all network syscalls on Linux CLI. Windows as administrator: an outbound firewall block for each operation. Standard-user Windows: disconnect the network manually.
The Linux desktop app (in the .deb and .rpm packages) runs every cryptographic operation outside its own window process and refuses insecure displays. Each card says whether it is active in the shipped app or planned.
The safeguards below come from the work on two new builds of QNSQY; each card carries its status. QNSQY is not FIPS 140-3 validated. QNSQY holds no CMVP certificate, and no lab has tested it. The CNSA 2.0 build carries no NSA, NIAP or CSfC approval. Details, limits and the roadmap: Approved-mode and CNSA 2.0 builds.
Built and tested internally. Not yet released. Approved-mode build: known-answer tests, including all six ML-KEM and ML-DSA parameter sets and NIST's ML-DSA rejection-path cases, plus a software integrity test (HMAC-SHA-512 of the program).
Built and tested internally. Not yet released. Any self-test failure puts the approved-mode build into an error state.
Built and tested internally. Not yet released. Run on every ML-KEM and ML-DSA key pair the approved-mode build generates.
Built and tested internally. Not yet released. On Linux a kernel filter (seccomp), installed at the start of every command before anything else runs, ends the process if it tries to use a network socket; tested with zero packets leaving a network namespace. It applies only to QNSQY's own process; other programs keep their network. On Windows the build has no network code path.
Released in the standard build since October 2026, and in the approved-mode builds. An extra guard against the x32 system-call route.
Released in the standard build since October 2026, and in the approved-mode builds. Each QNSQY process grants itself exactly the files and folders named in its command (inputs read-only, the output folder writable), besides the home and temporary folders, so data outside the home folder works with the sandbox still on.
Every algorithm we use is publicly documented. NIST publications, IETF RFCs, academic papers. You can verify our claims against the official specifications.
All releases are cryptographically signed. Verify the signature before running. SHA-256 checksums provided for every download. Releases since September 2026 also ship a software bill of materials (SBOM) of their dependencies, covered by the same signed checksums.
Found a vulnerability? Report it to [email protected]. We take responsible disclosure seriously and will work with you to address issues.
Full changelog with every release. Know exactly what changed. No silent updates. You control when and if you upgrade.
For those who want to verify our cryptographic claims, here are the official specifications:
Deep dives into the practical security topics behind QNSQY: how to operate it in air-gapped environments, how it compares to legacy disk encryption, and the hardware and key-management primitives that pair with it.
What air-gapped operation actually means, the threats it defeats, and how QNSQY enforces it on Linux via seccomp-bpf.
Why classical full-disk encryption is not post-quantum, and how QNSQY layers on top to protect data beyond the boot drive.
Side-by-side breakdown of cryptographic primitives, threat model, and operational use cases between QNSQY and VeraCrypt.
How M-of-N threshold schemes protect high-value keys when no single custodian should be able to act alone.
Planned, not in QNSQY yet: a YubiKey or other FIDO2 token as a hardware-bound second factor in front of decryption.
Time-locked encryption, key expiry policies, and why expiring access matters even when ciphertext lives forever.
What the Linux desktop app does today (Wayland only, and a separate sandboxed process for the cryptography) and what is planned (memfd_secret, pinentry isolation).
We're happy to discuss our approach. Contact our security team.