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."
18,703 NIST ACVP vectors pass byte-for-byte against expected output. Zero failures across 33 algorithm directories at 100% coverage. Replays ACVP-Server v1.1.0.42 (commit 15c0f3deeefbfa) against the same Rust crates QNSQY ships. Sweep wall-clock: 719.66 s (2026-06-03 sweep).
Out of 29,962 total. 11,259 documented skips for vector classes we do not implement (e.g., raw FFDH, custom-key SHAKE).
Every non-skipped vector matches the expected output. No discrepancies, no waivers, no retries.
33 of 50 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 algorithm implementations compiled into the shipped qnsqy binary's own source tree, plus internal end-to-end format tests. Anyone can reproduce it with the standalone harness published on the Validation page; full source access for customers and auditors is available on request under NDA. CMVP is on the roadmap.
Full write-up: 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, roughly 2,937 vectors 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 AES-256-GCM and XChaCha20-Poly1305 vectors test QNSQY's own AEAD code; the Ed25519, X25519, ML-DSA-44/65/87, ML-KEM-512/768/1024, 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 already do. 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. RSA-2048 cracked in hours, 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. NIST FIPS 206 (draft). 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. Levin-Micali-Rompel hash-based signatures. Security depends only on SHA-256 collision resistance. 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 data encryption generates unique ephemeral keys. Even if an attacker compromises one file's encryption key, they cannot decrypt other files. Past encryptions remain secure.
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. Everything happens locally on your device. There's no server to hack, no cloud to breach, no third party to subpoena.
On Linux CLI, kernel-level network blocking via seccomp-bpf ensures the application cannot connect to the internet. No phone home, no remote exploitation.
Platform Note: macOS uses deprecated sandbox_init() API (may not be enforced). Windows has no kernel-level network blocking; physically disconnect from network for air-gapped security. GUI versions cannot block network (require sockets for display).
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.
We don't use cloud services. There's nothing for providers to access.
We have nothing to turn over. Your data, passwords, and keys never leave your device.
seccomp-bpf blocks all network syscalls on Linux CLI. Windows/macOS: manually disconnect network.
The Linux Flatpak GUI implements comprehensive security hardening across display, memory, input, and trust surfaces. Every component is designed to protect against both local and remote attacks.
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.
Found a vulnerability? Report it to security@quantumsequrity.com. 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.
Pairing a YubiKey or other FIDO2 token with QNSQY to add 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.
How the Linux GUI is hardened with Wayland-only display, memfd_secret, pinentry isolation, and a seccomp-bpf sandbox.
We're happy to discuss our approach. Contact our security team.