FAQ

Quantum-safe encryption uses algorithms designed to resist attacks from both classical and quantum computers. All QNSQY tiers use hybrid ML-KEM + X25519 key encapsulation with AES-256-GCM authenticated encryption. ML-KEM-512 hybrid encryption is always free and unlimited on all tiers. Free tier uses ML-KEM-512 and ML-DSA-44. Pro adds ML-KEM-768/1024 plus all ML-DSA and SLH-DSA signatures. Business adds FN-DSA (Falcon), HQC, and LMS for maximum algorithm diversity across every NIST-approved PQC family, plus compliance features and organizational deployment. Core algorithms ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) were standardized by NIST on August 13, 2024. FN-DSA (FIPS 206 (draft)) is still in draft as of April 2026.

No, "Quantum Sequrity" is not a typo. QNSQY stands for QuaNtum SeQuritY. The stylized spelling is our intentional brand identity. Our domain is quantumsequrity.com. We provide quantum-safe data encryption software for protecting sensitive data against future quantum computer threats.

No. QNSQY is post-quantum data encryption that covers data at rest in any form: documents, databases, backups, replication streams, and cold-storage archives. The product ships as a CLI, GUI, TUI, and MCP server. Around the product we offer four scoped professional services for organizations migrating off classical cryptography: PQC readiness assessment, database migration to PQC, cold storage PQC migration, and migration-as-a-service (MaaS). Services are priced and scoped separately from the subscription. See Pricing.

ZIP encryption has several weaknesses: (1) Older ZIP uses ZipCrypto, which is cryptographically broken and can be cracked in minutes. (2) Modern ZIP uses AES, but with weak key derivation (PBKDF2) that's vulnerable to GPU-accelerated brute force. (3) Neither is quantum-resistant. QNSQY uses Argon2id (memory-hard, GPU-resistant), hybrid ML-KEM + X25519 key exchange, and AES-256-GCM encryption on all tiers. For files that need to stay secure for decades, ZIP encryption is inadequate.

For quantum resistance, yes. GPG and 7-Zip use traditional cryptography (RSA, ECDH, AES with PBKDF2) that quantum computers will eventually break. QNSQY specifically addresses this threat with NIST-approved post-quantum algorithms. Additionally, QNSQY uses Argon2id for key derivation, which is more resistant to brute-force attacks than the older algorithms used by GPG (S2K) and 7-Zip (PBKDF2). If you need files to stay encrypted for decades, QNSQY is the better choice.

Estimates vary, but most experts believe cryptographically relevant quantum computers (CRQCs) could arrive within 10-20 years. However, the threat is already real due to "harvest now, decrypt later" attacks. Adversaries are collecting encrypted data today, waiting to decrypt it when quantum computers become available. If your data needs to stay confidential for more than 10 years, you should be using post-quantum encryption now.

Data encryption, decryption, signing, and verification run locally and work offline. No data-operation telemetry is collected. Note on air-gap: The CLI does contact billing.quantumsequrity.com to validate the subscription tier and credit counter; the response is cached for up to 7 days of offline work. On Linux CLI, seccomp-bpf KillProcess-blocks ALL network syscalls at the kernel before any crypto operation; the billing check-in itself is pinned to billing.quantumsequrity.com by application-layer controls, since seccomp cannot filter by host. On Windows/macOS/GUI, there is no kernel-level enforcement; physically disconnect from the network for a true air-gap.

Yes. We run a test harness that replays the full ACVP-Server v1.1.0.42 vector tree (29,962 total vectors) against the same Rust crates QNSQY ships. As of the 2026-05-15 sweep, 18,703 vectors passed with zero failures. 11,259 vectors were skipped (parameter sets QNSQY does not implement, e.g. RSA, ECDSA, AES-CBC). 33 of 50 ACVP algorithm directories are at 100% coverage, including all 22 HMAC directories, ML-DSA keyGen + sigVer, ML-KEM keyGen, SLH-DSA across all 12 parameter sets, SHA-2-256/512/512-256, SHAKE-128, and XECDH-SSC. These are NIST ACVP test vectors replayed against the algorithm implementations compiled into the shipped qnsqy binary's own source tree, plus internal end-to-end format tests. A standalone, self-contained reproducer harness is published on the Validation page; full source access for customers and auditors is available on request under NDA. Note: this is reproducible test-vector evidence, not FIPS 140-3 / CMVP validation, and not an external audit. CMVP is on the roadmap. See the ACVP validation write-up and the Test Validation section in the Docs.

Your files cannot be recovered. This is by design. QNSQY uses zero-knowledge architecture: we never see your password and have no way to recover encrypted files. We recommend keeping secure backups of critical passwords using a reputable password manager. Business users have optional key escrow features for organizational recovery scenarios.

No. We have no access to your data content, your password, or your private keys. Data encryption and decryption happen locally on your device. There is no cloud storage of your data and no "master key." This is a fundamental security feature, not a limitation. If we could recover your data, so could anyone who compromised our systems. (For completeness: our billing server does hold subscription metadata such as your tier, credit counter, and device-binding hash, which is necessary to operate the service but never includes your data or passwords.)

Independent security audits are planned and will be published when completed. In the meantime, we use only public, peer-reviewed cryptographic standards that have been extensively analyzed by the security community: Argon2id (RFC 9106), AES-256-GCM (NIST SP 800-38D), ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), FN-DSA/Falcon (FIPS 206 (draft)), HQC, LMS (SP 800-208), and BLAKE3. We welcome security researchers to examine our implementation.

This is exactly why NIST selected multiple algorithm families based on different mathematical problems. ML-KEM (lattice-based) has been extensively analyzed since 2017. But if lattice cryptography were weakened, QNSQY Business includes alternatives: HQC (code-based KEM), LMS (hash-based signatures), and FN-DSA (NTRU lattice, different structure from ML-KEM). This algorithm diversity is the strongest defense against future cryptanalytic breakthroughs.

The source code is proprietary. However, all cryptographic algorithms used are public standards with multiple independent implementations. You can verify our security claims by examining the NIST FIPS publications (203, 204, 205, 206), SP 800-208, the Argon2 RFC (9106), and other relevant specifications. We believe in "open standards, not necessarily open source." The security comes from the algorithms, not obscurity.

Contact [email protected] with details of the vulnerability. We take responsible disclosure seriously and will work with you to address issues. Please allow us reasonable time to investigate and fix issues before public disclosure. We do not have a formal bug bounty program, but we acknowledge security researchers who help improve our products.

Free tier: up to 100 MB per file. Pro: up to 25 GB per file. Business: unlimited file size with streaming encryption (low memory usage). Streaming encryption processes files in chunks without loading the entire file into memory.

v7.2.37 ships for Linux x86_64 and Windows 10 (1809+) / 11 x86_64. Linux requires glibc 2.35 or newer, verified on Ubuntu 22.04 / 24.04 / 24.10 / 25.04 / 25.10, Debian 12 / 13, Fedora 40 / 41 / 42 / 43 / 44, AlmaLinux 10 (RHEL 10 shares the same glibc 2.39 and works). Not yet supported: macOS, Linux ARM64 / aarch64, FreeBSD, mobile. Distros with glibc < 2.35 (Ubuntu 20.04, Debian 11, RHEL/Rocky/AlmaLinux 9) are not supported.

QNSQY encrypts individual files. To encrypt a folder, first archive it (using tar, zip without encryption, or similar), then encrypt the archive. For example: tar -cf folder.tar myfolder/ && qnsqy encrypt -i folder.tar. This gives you a single encrypted file containing your entire folder structure.

Yes. QNSQY includes both a graphical interface (GUI) and command-line interface (CLI). The GUI provides drag-and-drop encryption; the CLI fits automation and scripting. Both interfaces provide the same encryption capabilities and are included with every plan.

Yes. The encrypted file format (.qs) is platform-independent. Files encrypted on any operating system can be decrypted on any other supported operating system. The same applies across tiers, and files are cross-compatible regardless of which tier created them.

Visit our pricing page to subscribe to Pro ($29/mo), Business ($149/mo, self-serve), or Enterprise (contact sales). Log in with qnsqy login. Your existing encrypted files will continue to work; the file format is identical across all tiers. Pro gives you ML-KEM-512/768 + ML-DSA-44/65 unlimited (0 credits), plus 1,200 credits/mo for ML-KEM-1024/ML-DSA-87/SLH-DSA. Business makes everything unlimited. Enterprise adds a signed SLA, dedicated engineering channel, quarterly 4-hour readiness consult, white-glove onboarding, and a named customer-success contact (air-gap license and HSM integration are v7.3 roadmap). Pay-as-you-go: $0.05/credit.

QNSQY uses a tier-based model with credit-free algorithms. Free ($0): ML-KEM-512 + ML-DSA-44 are unlimited (0 credits, no file limit); 100 MB limit for advanced algorithms. Pro ($29/mo): ML-KEM-512/768 + ML-DSA-44/65 are unlimited; 1,200 credits/mo for ML-KEM-1024, ML-DSA-87, SLH-DSA. Business ($149/mo, self-serve): every algorithm is unlimited (0 credits), no file limit. Decrypt, verify, hash, keygen, and shred are always free on all tiers. PAYG: $0.05/credit. See our pricing page for full details.

You can cancel your subscription at any time. We encourage you to try the Free tier first to ensure QNSQY meets your needs before subscribing to Pro or Business.

The Free tier is licensed for personal, non-commercial use only. For commercial use, business environments, or organizational deployment, please subscribe to Pro or Business. The core encryption is identical; higher tiers add more algorithms, larger file limits, and commercial licensing.

Free: unlimited personal devices. Pro: licensed per-seat, with volume discounts available. Business: licensed per-seat, same as Pro with compliance features and organizational deployment. Contact us for site licenses if you need organization-wide deployment.

QNSQY supports 12+ algorithm families across three tiers:

All tiers: AES-256-GCM, XChaCha20-Poly1305, Argon2id, BLAKE3, X25519 + Ed25519
Free: ML-KEM-512 + X25519 hybrid, ML-DSA-44
Pro: ML-KEM-512/768/1024, ML-DSA-44/65/87, SLH-DSA, ML-DSA+Ed25519 hybrid
Business: Everything in Pro plus FN-DSA-512/1024 (Falcon, FIPS 206 (draft)), FN-DSA+Ed25519 hybrid, HQC-128/192/256 + X25519, LMS (SP 800-208), compliance features, and organizational deployment

FN-DSA (Fast-Fourier NTRU Digital Signature Algorithm), also known as Falcon, is a post-quantum signature scheme standardized as NIST FIPS 206 (draft). It produces much smaller signatures than ML-DSA (roughly 666 bytes vs 2420 bytes at comparable security), making it ideal for bandwidth-constrained applications. QNSQY Business supports FN-DSA-512 (NIST Level 1) and FN-DSA-1024 (Level 5), both standalone and as hybrids with Ed25519.

HQC (Hamming Quasi-Cyclic) is a code-based key encapsulation mechanism selected in NIST's Round 4. Unlike ML-KEM which is lattice-based, HQC is based on error-correcting codes, a completely different mathematical foundation. This provides algorithm diversity: if lattice cryptography were ever weakened, HQC would remain secure. QNSQY Business supports HQC-128/192/256, always hybridized with X25519 for defense-in-depth.

LMS (Leighton-Micali Signature) is a hash-based signature scheme standardized in NIST SP 800-208. Unlike ML-DSA or FN-DSA, LMS is "stateful": each signature permanently consumes a leaf from a one-time signature tree. The private key must be updated after every signature, and you must never reuse a leaf (doing so breaks security). QNSQY handles this automatically with atomic key file updates. LMS security depends purely on the strength of hash functions, making it arguably the most conservative post-quantum signature choice.

Pro ($29/mo): ML-KEM-512/768 + ML-DSA-44/65 are unlimited (0 credits, no file limit). 1,200 credits/mo for ML-KEM-1024, ML-DSA-87, SLH-DSA. Includes batch ops, rekey, password vault, audit logging, and 25 GB file limit for credit-costing algorithms. Business ($149/mo, self-serve): every algorithm is unlimited (0 credits): ML-KEM, ML-DSA, SLH-DSA, FN-DSA, HQC, LMS. No file size limit. Adds threshold encryption, steganography, timelock, deniable encryption, polyglot, migration tools, compliance features, priority support, and organizational deployment. PAYG: $0.05/credit.

Time-lock encryption (Business only) creates encrypted files that are bound to a time duration. You set a duration (e.g. 30 days), and the encrypted file cannot be decrypted until that time has passed, or can be set to auto-expire after the duration. This is useful for embargoed documents, timed releases, or compliance scenarios where data must remain sealed for a specific period. Usage: qnsqy timelock encrypt -i file --duration 30d

The PQ Migration Scanner (Business only) scans directories for files encrypted with quantum-vulnerable algorithms (RSA, ECDSA, classical key exchange) and reports which files need migration to post-quantum cryptography. Combined with the migrate command, you can then batch re-encrypt these files using post-quantum algorithms. Usage: qnsqy scan /path/to/data/ then qnsqy migrate /path/to/data/. This helps organizations systematically transition their encrypted data to quantum-safe protection.

The Password Vault (Pro+) is an encrypted credential manager built into QNSQY. Your master password derives an AES-256-GCM key via Argon2id, encrypting all entries as a single blob (zero metadata leakage). Supports storing names, usernames, passwords, URLs, notes, and tags. Commands: qnsqy vault init, qnsqy vault add, qnsqy vault get, qnsqy vault list, qnsqy vault remove, qnsqy vault edit, qnsqy vault export, qnsqy vault import, qnsqy vault rekey. Clipboard auto-clears after 10 seconds.

Deniable Encryption (Business only) creates encrypted containers with two separate password-protected compartments. One password reveals a decoy payload; a different password reveals the real data. An adversary who forces you to reveal a password cannot prove a second compartment exists. Usage: qnsqy deniable create -o container then qnsqy deniable open -i container.

Threshold Encryption (Business only) provides M-of-N encryption where multiple recipients must cooperate to decrypt. For example, 3-of-5 means any 3 out of 5 keyholders can decrypt the file. Usage: qnsqy threshold-encrypt -i file -m 3 -r key1.pub -r key2.pub -r key3.pub -r key4.pub -r key5.pub and qnsqy threshold-decrypt -i file.qs --key key1 --key key2 --key key3.

Keyfile Encryption (Business only) uses a keyfile instead of a password for encryption/decryption. The keyfile contains a high-entropy random key, eliminating the risk of weak passwords. Commands: qnsqy keyfile generate -o mykey.qskf, qnsqy keyfile encrypt -i file --keyfile mykey.qskf, qnsqy keyfile decrypt -i file.qs --keyfile mykey.qskf. Note: keyfile encryption uses AES-256-GCM directly without KEM.

Yes. BLAKE3 standalone hashing is available on all tiers (including Free). Use qnsqy hash -i file to compute a BLAKE3 hash, or qnsqy hash -i file -a sha3 for SHA3-256. Verify with qnsqy hash-verify -i file --hash <expected-hash>. Recursive directory hashing is supported with -r.

The symmetric command (Pro+) provides a simplified encryption mode using AES-256-GCM or XChaCha20-Poly1305 directly with a password. Unlike the standard encrypt command, it doesn't use hybrid KEM or generate recipient keypairs. Just straightforward password-to-AES encryption. Usage: qnsqy symmetric -i file to encrypt, qnsqy symmetric -i file.qs -d to decrypt.

An organization lets a Business-tier team share one quantum-safe standard: shared membership, role-based control, single sign-on, a signed encryption policy the client enforces, and a per-organization audit log. Organizations are a Business feature. Free and Pro accounts are always individual. See the Organizations and Teams section of the docs for the full walkthrough.

Owner is the person the organization is created around and has full control. Admin can manage members and organization settings. Member is a standard team member covered by the organization's tier and policy. A person belongs to one organization at a time.

An administrator adds people from the organization admin portal by email. If the person already has a QNSQY account they are added directly; if the email is new, an account is created and they receive a one-time sign-in link valid for 72 hours. The link never contains a password: the new member signs in with it, then sets their own password from their dashboard.

Each organization can connect its own identity provider so members sign in with corporate credentials. QNSQY supports OpenID Connect (OIDC) and SAML 2.0, configured per organization in the org admin portal, with a Test action to verify the connection before rollout. A device-code flow lets the QNSQY CLI authenticate through your provider as well.

Yes. A Business organization can publish a signed encryption policy that sets minimum cryptographic requirements, for example a minimum algorithm strength or a requirement to use post-quantum protection. The policy is signed with Ed25519 so it cannot be tampered with in transit, and each member's QNSQY client fetches and enforces it at runtime: an operation that would fall below the policy is refused locally before any data is processed.

No. A person belongs to one organization at a time, which keeps their tier and policy unambiguous. To move someone between organizations, remove them from the first one before adding them to the second. Removing a member fully clears their membership, so their tier and policy revert to their individual account.

test-no-mlock is a Cargo feature flag that disables mlock() system calls during tests. mlock() locks memory pages to prevent secrets from being swapped to disk, a critical security feature in production. However, it requires either root privileges or a high RLIMIT_MEMLOCK value. In CI environments, containers, or unprivileged accounts, mlock() may fail. The test-no-mlock flag compiles out all mlock() calls so tests can run anywhere. Never use this flag in production builds. Usage: cargo test --features test-no-mlock. See the full explanation in the Docs.

QNSQY's product source is closed; source access for customers and auditors is available on request under NDA. With source access: install Rust via rustup.rs (stable channel), a C compiler (gcc/clang), and cmake. Then: cargo build for debug CLI, cargo build --release for optimized CLI, or cargo build --release --features gui for GUI. Tests: cargo test --features test-no-mlock. See the complete build guide.

Key flags: gui (Slint GUI), tui (terminal UI), billing (SaaS billing, on by default), test-no-mlock (skip mlock in tests), minimal (smallest attack surface), hardened (strict security), paranoid (maximum security). The tier-enterprise and tier-ultra flags are legacy no-ops; tier is determined at runtime via billing. See all feature flags explained.

QNSQY sets unsafe_code = "warn" at the workspace level for visibility. A small number of unsafe blocks exist in low-level code: seccomp BPF filter setup, mlock()/madvise() syscalls, and some FFI bindings to C crypto libraries. Each block is individually annotated with #[allow(unsafe_code)] and has been security-audited. The warn level ensures any new unsafe usage is immediately visible during development and CI. See the Docs troubleshooting section.

The password you entered doesn't match the password used to encrypt the file. Check for typos, caps lock, or keyboard layout issues. Passwords are case-sensitive. If you've forgotten the password, the file cannot be recovered.

The encrypted file has been modified or corrupted since it was created. This could be due to incomplete file transfer, disk errors, or intentional tampering. The file cannot be decrypted. If you have a backup of the original encrypted file, try that instead.

The file exceeds your tier's size limit. Free: 100 MB. Pro: 25 GB. Business: unlimited. Upgrade to a higher tier for larger files, or split the file into smaller parts before encrypting.

This almost always means QNSQY was run with sudo or as the root user. Your license is tied to your normal user account and machine; running as root looks like a different user, so the saved subscription no longer matches and QNSQY falls back to Free. Run qnsqy as your normal user, never with sudo. If the tier is still wrong, run qnsqy login, make sure the machine can reach billing.quantumsequrity.com once, and let it revalidate online. After one successful online check the correct tier is cached for offline use.

Your operating system ships a glibc older than 2.35, the minimum QNSQY requires. Common cases: Debian 11, Ubuntu 20.04, Rocky Linux 9, AlmaLinux 9, and RHEL 9 (all 9.x ship glibc 2.34, below the 2.35 floor). Move to a supported release (Ubuntu 22.04+, Debian 12+, Fedora 40+, AlmaLinux 10, RHEL 10) and reinstall. There is no workaround on an older glibc: the binary links symbols that are not present before 2.35.

Your Node.js is older than 18, so npm skipped the optional, platform-specific dependency that carries the binary. Upgrade to Node 18 or newer (which ships npm 9+), or force the optional dependency with npm install -g qnsqy --include=optional. This is by design: the wrapper stops with a clear message rather than leaving you a broken command.

That is the intended runtime guard, not a crash. The npm wrapper checks your glibc version before launching the binary; on a sub-2.35 system it stops cleanly with that message instead of failing with a confusing linker error. The fix is the same as the GLIBC error above: install QNSQY on a supported OS with glibc 2.35 or newer.

No, this is expected and safe. The QNSQY dnf repository is configured with repo_gpgcheck=1 and gpgcheck=0: dnf verifies the repository metadata with our GPG key, and that signed metadata pins the exact SHA-256 of every package. Integrity is enforced at the metadata layer, which is why dnf notes it skipped the separate per-package OpenPGP check. The package you install is still cryptographically pinned to what we published.

Three independent layers cover every release, and any one is enough. (1) SHA-256: compare your file's hash against the published checksums.txt (sha256sum on Linux, certutil -hashfile <file> SHA256 or Get-FileHash on Windows). (2) Post-quantum ML-DSA-87: qnsqy verify-release checksums.txt checksums.txt.sig verifies the signed manifest with the key embedded in every QNSQY binary. (3) cosign / Sigstore: cosign verify-blob against the public transparency log. Installing through the apt or dnf repo verifies signed metadata automatically. The exact commands are on the download page.

The binary self-checks an embedded BLAKE3 hash of its own code at launch. A warning means the file on disk no longer matches the hash it shipped with, usually a corrupted or partial download, or tampering. Do not trust that copy. Reinstall from an official channel (npm, the apt or dnf repo, or the signed downloads on this site) and verify the SHA-256 as above.

Pick one channel and stay on it. Check what you have at any time with qnsqy version.

npm: install npm install -g qnsqy, upgrade npm install -g qnsqy@latest, uninstall npm uninstall -g qnsqy.

apt (Debian / Ubuntu): after adding the QNSQY apt repo, sudo apt update && sudo apt install qnsqy; the same command upgrades; remove with sudo apt remove qnsqy.

dnf (Fedora / RHEL / AlmaLinux): after adding the repo, sudo dnf install qnsqy; upgrade sudo dnf upgrade qnsqy; remove sudo dnf remove qnsqy.

Windows: run the installer to set up or update, or replace the portable .exe with the newer one; uninstall via Settings > Apps (installer), or just delete the portable .exe.

Both contain the same single binary. The installer (qnsqy-setup-7.2.37.exe) sets QNSQY up system-wide, adds it to your PATH, and creates Start-menu entries; use it for a normal desktop install. The portable build (qnsqy-7.2.37-x86_64.exe) needs no installation: run it from any folder or a USB stick, which suits locked-down or air-gapped machines. On a fresh download Windows SmartScreen may say "Unknown Publisher"; the next answer explains why that is expected.

MCP: run qnsqy --mcp to expose QNSQY's operations to any MCP-compatible agent over stdio (JSON-RPC). Point your agent's MCP client at that command and it can call tools such as encrypt, decrypt, sign, verify, and hash under the same tier rules as the CLI. REST API: for server-side and programmatic integrations, see the Developer API, which exposes the same cryptographic operations over HTTP with an API key. Both run locally under your control; your keys and data are never sent to us.

Your data is safe and the binary is authentic. QNSQY releases are signed with NIST FIPS 204 ML-DSA-87 post-quantum signatures: every release ships a SHA-256 checksums.txt manifest plus an ML-DSA-87 signature (checksums.txt.sig) over it, cryptographically stronger than Microsoft's legacy Authenticode. Windows does not yet natively verify post-quantum signatures, so SmartScreen labels the publisher as "Unknown".

A Microsoft Authenticode certificate costs money and takes weeks of vetting. We will add it as a convenience layer in a later release. The cryptography protecting the binary itself is unaffected, and we chose to ship real post-quantum signatures today rather than wait on the legacy certificate path.

You can independently verify the binary two ways: (1) certutil -hashfile qnsqy.exe SHA256 or Get-FileHash qnsqy.exe matched against the SHA-256 on the download page, or (2) qnsqy verify-release checksums.txt checksums.txt.sig from any existing QNSQY install, which verifies the signed checksums manifest with the ML-DSA-87 key embedded in the binary (BLAKE3 fingerprint 50af23b47dca8d74; the same public key is published at quantumsequrity.com/keys/release-mldsa87.pub), then match your download's hash against the verified manifest. Once verified, click "More info" in the SmartScreen dialog, then "Run anyway". See If Windows warns you on the download page for the full step-by-step.

Cryptography designed to remain secure against attacks by both classical and quantum computers. The U.S. National Institute of Standards and Technology has standardized three primary algorithms so far: ML-KEM (FIPS 203, key encapsulation), ML-DSA (FIPS 204, signatures), and SLH-DSA (FIPS 205, hash-based signatures). QNSQY implements all three plus FN-DSA (FIPS 206 draft), LMS (SP 800-208), and HQC.

Post-quantum algorithms are new. NIST finalized them in August 2024 and they have less peer-reviewed cryptanalysis than classical algorithms have had over 30 years. By hybridizing (ML-KEM with X25519, ML-DSA with Ed25519), an attacker has to break both the lattice and the elliptic curve simultaneously. NSA CNSA 2.0 also recommends hybrid during the transition. Pure-KEM mode is available as a Business opt-in for operators who want it.

No. The cryptographic algorithms QNSQY implements are NIST-standardized, but the QNSQY binary itself does not carry a FIPS 140-3 Cryptographic Module Validation Program certificate. CMVP submission is a planned use of seed funds. The product is FIPS-compliant in the algorithm-usage sense, not FIPS-validated.

No. QNSQY does not sign BAAs today. The product never sees customer file content (data stays on the operator's machine; only encrypted billing metadata transits the network), so the legal basis for a BAA is narrow. Operators can use QNSQY as a technical control inside their existing HIPAA program, and the Breach Notification Safe Harbor under 45 CFR 164.402(2) applies to QNSQY-encrypted data when keys remain uncompromised.

ACVP is NIST's Automated Cryptographic Validation Protocol, the same vector set NIST-accredited CMVP laboratories use to certify FIPS modules. Our most recent run, dated 2026-05-19, covered 50 ACVP test groups containing 18,703 individual test vectors with zero failures and a runtime of 536 seconds. The raw log and machine-readable summaries are at /validation. This is algorithm-level evidence, not a CMVP module certificate.

A class of attack where an adversary captures encrypted data today and stores it until quantum computers are powerful enough to decrypt it. NSA and CISA assessments confirm this is happening. Data with a confidentiality horizon of 10 years or more (medical records, contract archives, intellectual property, government communications) is the primary exposure surface. QNSQY closes the data-at-rest piece of that exposure. See our deeper explainer.

84 tools as of v7.2.19, spanning encryption, decryption, signing, verification, hashing, key generation, threshold operations, escrow, vault management, audit log access, scan and migrate workflows, and account management. Same tier and billing enforcement as the CLI. Rate-limited 60 calls per minute global plus per-tool caps on destructive operations. Private keys never returned over MCP.

Yes. Tier is determined at runtime via the billing API. The Cargo feature flags paid-pro and paid-business control which subcommands are compiled into the binary but do NOT bypass billing enforcement. Compile-time tier-override flags were removed in 2026 Q1 (R51 cleanup) because they leaked into builds and bypassed billing entirely. Tier is therefore not changeable by recompilation.

The client carries a 7-day grace period plus a 24-hour offline extension. During that window, cached subscription state allows continued operation. The cache is bound to the machine key plus API key hash (BLAKE3) so it cannot be moved to another machine. If the grace window expires, paid features fall back to Free-tier behavior; encrypt and decrypt of existing files still work.

Source-available for audit on request, not open source under an OSI-approved license. The license is proprietary. Linux and Windows binaries are distributed at /download with BLAKE3 integrity hashes embedded in the binary itself. A subset of components are public on GitHub under quantumsequrity; the full source is provided under NDA to evaluators and customers.

NSA's Commercial National Security Algorithm Suite 2.0 mandates that new National Security Systems start post-quantum migration on January 1, 2027. Phased deprecation of RSA and ECC continues through 2030, with full disallowance by 2035 under NIST SP 800-131A Rev 3 alignment. QNSQY's algorithm coverage (ML-KEM-1024, ML-DSA-87, LMS, SLH-DSA, AES-256, SHA-384/512) maps to CNSA 2.0 Level V.

Partially. qnsqy shred does a 3-pass overwrite, which works well on traditional spinning disks. On SSDs with wear leveling, on copy-on-write filesystems (btrfs, ZFS), or on shingled-magnetic-recording disks, overwrite cannot reach every prior copy of the data. The honest recommendation for SSDs is full-disk encryption with secure-erase at decommission time. Use qnsqy shred as defense in depth, not as a sole data-destruction guarantee.

Not yet. macOS pipeline is on the roadmap; Apple notarization and code signing are part of the Speedrun use-of-funds plan. Today QNSQY ships for Linux x86_64 (glibc 2.35 or newer) and Windows 10 / 11. macOS users can compile from source under NDA.

Not yet. All audits to date are in-house multi-agent reviews; the audit history through 2026-05-25 totals 277 individual reports across roughly 32 distinct rounds since 2026-02-05. An independent third-party cryptographic code audit is in the use-of-funds plan and would be a prerequisite for federal procurement and FIPS 140-3 submission.

Linux x86_64 with glibc 2.35 or later: Ubuntu 22.04, 24.04, 24.10, 25.04, 25.10, rolling; Debian 12 and 13 (trixie); Fedora 40, 41, 42, 43, 44; AlmaLinux 10; RHEL 10. Not supported on older glibc: Debian 11, Ubuntu 20.04, Rocky 9, AlmaLinux 9, RHEL 9 (all 9.x ship glibc 2.34). The binary is built against the glibc 2.35 baseline.