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 by default 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 the NIST-approved families plus pre-standard FN-DSA and HQC, 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. FIPS 206 for FN-DSA is not yet published (October 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.

Encryption, decryption, signing and verification run on your device and work offline. What goes over the network: when you are signed in, QNSQY checks in with billing.quantumsequrity.com before an operation, sending the operation type, the data size, the algorithm and the program version, never file names or contents, and afterwards whether it succeeded and how long it took; the answer is cached, so you can keep working offline for up to 7 days. Remote backup (push, pull, sync), if you set it up, sends only ciphertext to the storage you choose. On Linux, after that check, seccomp-bpf blocks every network call at the kernel before any cryptographic work, including operations started from the desktop app, which run in a separate command-line process. seccomp cannot filter by host, so the check-in itself is pinned to billing.quantumsequrity.com by application-layer controls. On Windows, run as administrator, a firewall rule blocks QNSQY's outbound traffic during each operation; otherwise, disconnect the network for a true air gap. There is no macOS build yet.

Yes. We run a test harness that replays NIST's ACVP-Server v1.1.0.43 vector tree against the same open-source Rust crates QNSQY ships. In the 2026-09-24 sweep, 19,769 vectors passed with zero failures, out of 31,071 attempted. 11,302 vectors were skipped, each with a logged reason (options QNSQY does not implement, such as bit-oriented hash messages, SP 800-56C two-step key derivation, Ed448 and Curve448). 36 of 55 ACVP algorithm directories are at 100% coverage, including all 22 HMAC directories, ML-KEM keyGen and encapDecap, ML-DSA keyGen, sigGen and sigVer, SLH-DSA across all 12 parameter sets, SHA-2-256/512/512-256, and SHAKE-128. These NIST ACVP test vectors test the open-source libraries compiled into the shipped qnsqy binary, not QNSQY's own code; QNSQY's own code is tested separately (own-code vector suites, and Wycheproof ML-KEM and ML-DSA vectors run through its own paths), 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 June 2026 ACVP 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 holds your account and subscription records, a device-binding hash, and a record of each signed-in operation: its type, data size, result and duration. None of it 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 (FIPS 206, not yet published; pre-standard Falcon implementation), 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.

Command line: on Free, encryption has no file-size limit (Free uses ML-KEM-512, which has none). Pro has no limit with ML-KEM-512 or ML-KEM-768, and a 25 GB limit per file with ML-KEM-1024. Business has no limit. Files are encrypted in chunks, so a large file does not need to fit in memory. Desktop app: the current release is stricter and will not encrypt a file over 100 MB on Free or over 25 GB on Pro, whatever the algorithm. For larger files, use the command line.

QNSQY ships for Linux x86_64 and ARM64 and Windows 10 (1809+) / 11 x86_64. Linux requires glibc 2.28 or newer, except the static build. The last full distribution test ran in October 2026, in containers, on the RHEL 8 and 9 families (Red Hat UBI 8 and 9, AlmaLinux 8 and 9, Rocky Linux 8 and 9, Oracle Linux 8 and 9, CentOS Stream 9), AlmaLinux 10, Amazon Linux 2023, Fedora 40 / 41 / 42 / 43 / 44, Ubuntu 20.04 / 22.04 / 24.04, Debian 11 / 12 / 13, openSUSE Leap 15.6 and SUSE Linux Enterprise 15 SP6. ARM64 was tested on ARM64 cloud servers, in AlmaLinux 8, 9 and 10, Amazon Linux 2023, Fedora 44, Debian 11, 12 and 13, Ubuntu 20.04, 22.04 and 24.04, openSUSE Leap 15.6 and SUSE Linux Enterprise 15 SP6 containers on one Ubuntu 24.04 kernel, not yet on ARM64 desktops. A static Linux build for x86_64 and ARM64, without the desktop app, is for systems without glibc, such as Alpine. Not yet supported: macOS, FreeBSD, mobile. Distros with glibc older than 2.28 (Ubuntu 18.04, RHEL and CentOS 7, Amazon Linux 2) are not supported.

Yes. Point encrypt at the folder: qnsqy encrypt -i myfolder -o myfolder.qs. QNSQY packs the folder into an archive, encrypts it into one file and wipes the temporary archive; while it works, that plaintext archive sits briefly in the temporary folder. Decrypting restores the folder. A file is unpacked as a folder only when it was encrypted as one, and links or paths that would escape the target folder are refused.

Yes. QNSQY includes both a graphical interface (GUI) and command-line interface (CLI). The desktop app covers the everyday operations with forms and file pickers; the CLI fits automation and scripting and has every option. Both are included with every plan. The desktop app in the current release has stricter file-size limits than the command line (see the file-size answer).

Yes. The encrypted file format (.qs) is platform-independent. Files encrypted on one supported operating system can be decrypted on the other (Linux and Windows; there is no macOS build yet). One plan rule applies: in the current release, a file made on a paid plan opens only on that plan or a higher one (see the answer on what happens when a paid plan ends).

Visit our pricing page to subscribe to Pro ($29/mo), Business ($49 per user a month, self-serve), or Enterprise (contact us; pricing depends on scope). 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/1024 + ML-DSA-44/65/87 and SLH-DSA, all unlimited with no metering. 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 (an offline licence exists in the CNSA 2.0 edition, which is not released; HSM integration is planned; no dates).

QNSQY uses a flat-fee tier model with no usage metering. Free ($0): ML-KEM-512 + ML-DSA-44 are unlimited, with no file-size limit on the command line. Pro ($29/mo or $290/yr): ML-KEM-512/768/1024 + ML-DSA-44/65/87 and SLH-DSA are all unlimited, no metering; no file-size limit up to ML-KEM-768, 25 GB per file with ML-KEM-1024. Business ($49 per user a month or $490 per user a year, self-serve): every algorithm is unlimited, no file limit. Decrypt, verify, hash, keygen and shred are never metered. In the current release, a file made on a paid plan opens only on that plan or a higher one. 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: up to 3 devices. Pro: up to 5 devices. Business: up to 5 devices per user, and each person who uses QNSQY at work needs their own Business subscription. For a team on one bill, or organization-wide use, contact us.

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 (FIPS 206, not yet published; pre-standard Falcon implementation), 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 that NIST is standardizing as FIPS 206 (not yet published). 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 or $290/yr): ML-KEM-512/768/1024 + ML-DSA-44/65/87 and SLH-DSA are all unlimited, no metering; no file-size limit up to ML-KEM-768, 25 GB per file with ML-KEM-1024. Includes batch ops, rekey, password vault, and audit logging. Business ($49 per user a month or $490 per user a year, self-serve): every algorithm is unlimited: 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.

Time-lock encryption (Business) locks a file behind a puzzle that takes about the chosen time to solve (for example 30 days) on hardware like the machine it was calibrated on; faster hardware solves it sooner, and decrypting means doing that sequential work. The delay itself is classical: it rests on a 2048-bit RSA number, which a large quantum computer could factor, so add a password or a recipient's key to keep the file post-quantum. This is useful for embargoed documents and timed releases. Usage: qnsqy timelock encrypt -i file --duration 30d

The PQ Migration Scanner (free on every plan) 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 (Business), you can then re-encrypt these files with post-quantum encryption. 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 (Pro and Business) 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-256 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), configured per organization in the org admin portal, with a Test action to verify the connection before rollout. SAML 2.0 is not available yet. 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.

QNSQY's source code is closed. Customers and auditors can get read access under a non-disclosure agreement; contact us. The test-vector harness on the Validation page is public and needs no QNSQY source.

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 is over the limit for your plan and algorithm. On the command line, ML-KEM-512 has no limit on any plan, ML-KEM-768 none on Pro and Business, and ML-KEM-1024 is limited to 25 GB per file on Pro (no limit on Business). The desktop app in the current release stops at 100 MB per file on Free and 25 GB on Pro whatever the algorithm; use the command line for larger files.

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.28, the minimum QNSQY requires. Common cases: Ubuntu 18.04, RHEL and CentOS 7, Amazon Linux 2. Move to a supported release (RHEL 8+ and its rebuilds, Amazon Linux 2023, Ubuntu 20.04+, Debian 11+, Fedora 40+, SLES 15 SP6) and reinstall. There is no workaround on an older glibc: the binary links symbols that are not present before 2.28.

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 system with glibc older than 2.28 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.28 or newer.

It means your repository file still says gpgcheck=0, as our instructions did before 18 October 2026. Your installs were still protected: dnf verifies the repository metadata with our GPG key (repo_gpgcheck=1), and that signed metadata pins the exact SHA-256 of every package. Every QNSQY package is also signed with the same key, so turn on the per-package check once with sudo sed -i 's/^gpgcheck=0/gpgcheck=1/' /etc/yum.repos.d/qnsqy.repo. dnf then checks each package's own signature and no longer prints the message.

Two checks cover every release. (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). This shows the file matches the published list. (2) Post-quantum ML-DSA-87: qnsqy verify-release checksums.txt checksums.txt.sig proves the list itself was signed with our release key, which is embedded in every QNSQY binary. The current release also has (3) a Sigstore (cosign) signature on the website's list (quantumsequrity.com/downloads/checksums.txt), made with a short-lived certificate tied to our public GitHub build workflow and recorded in the public Rekor transparency log; cosign verify-blob checks it. 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-<version>.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-<version>-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. From your own code: call the qnsqy command line; it can take the API key from the environment. A Developer API over HTTP is planned and not available yet. Both the MCP server and the command line run locally under your control; your keys and data are never sent to us.

This is expected: the Windows installer is not yet signed with a Windows code-signing (Authenticode) certificate, so Windows does not know the publisher. Check the download before you run it. 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, which, unlike Authenticode's RSA or ECDSA, is designed to resist quantum attacks. 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 ML-DSA-87 check of the download 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, not yet published; pre-standard Falcon implementation), 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's CNSA 2.0 permits hybrids during the transition for interoperability but does not require or recommend them; NIST and IETF are the bodies recommending hybridization. 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 uses the FIPS 203/204/205 algorithms but is not FIPS-validated. No lab has tested QNSQY. FIPS 140-3 validation is on the roadmap, not started; it needs an accredited lab and NIST review. Our approved-mode and CNSA 2.0 builds (built and tested internally, not yet released) do not change this; see Approved-mode and CNSA 2.0 builds.

A build of QNSQY that allows approved algorithms only: ML-KEM (FIPS 203), ML-DSA (FIPS 204), AES-256-GCM, SHA-256/384/512, SHA3-256 for the hash command, HMAC-SHA-512 and PBKDF2-HMAC-SHA-512. The choice is fixed when the program is built; no flag, setting or license can switch it off. It runs start-up self-tests before first use (known-answer tests and a software integrity test) and a pairwise consistency test on every ML-KEM and ML-DSA key pair it generates; any self-test failure puts it into an error state (exit code 70, no output). Features that are not approved, such as the vault and steganography, stay in the standard build; its MCP server for AI agents offers only the tools of approved commands. Status: built and tested internally (on Linux and in a Windows 11 virtual machine). Not yet released. QNSQY is not FIPS 140-3 validated. QNSQY holds no CMVP certificate, and no lab has tested it. Details and limits: Approved-mode and CNSA 2.0 builds.

A variant of the approved-mode build for defense and national-security users, narrowed to the CNSA 2.0 algorithms: ML-KEM-1024, ML-DSA-87, AES-256-GCM and SHA-384/SHA-512, with no SHA-3 and no passwords. Every encrypted item is signed with ML-DSA-87; opening it requires the sender's public key, and the signature is checked before any plaintext is written. It runs with an offline license signed with ML-DSA-87 and bound to one device, with no billing server and no sign-in, and it makes no network use: on Linux a kernel filter (seccomp), which applies only to QNSQY's own process, ends the process if it tries to use a network socket, and on Windows the build has no network code path. Status: built and tested internally (on Linux and in a Windows 11 virtual machine). Not yet released. 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 and limits: CNSA 2.0 build.

There is no release date yet. Both builds are built and tested internally and not yet released. The full test suite on all three builds ran on the October 2026 release candidate, and the Windows 11 test with a standard (non-administrator) user is done. Still to come: release builds from a clean commit, tests on 24 Linux distributions, two live end-to-end runs, and tests on real hardware (a TPM chip, a security token, a Windows system for package detection). The full list is in the roadmap. For availability and pricing, contact us.

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. The breach notification safe harbor (45 CFR 164.402(2)) covers protected health information encrypted as HHS guidance describes (for data at rest, consistent with NIST SP 800-111) whose keys were not compromised. Whether QNSQY-encrypted data qualifies is for your compliance officer to judge: QNSQY is not FIPS 140-3 validated and has not been assessed against SP 800-111.

ACVP is NIST's Automated Cryptographic Validation Protocol, the protocol and test vectors behind NIST's algorithm validations (CAVP), on which a FIPS 140-3 module validation builds. Our most recent run, dated 2026-09-24, covered 55 ACVP directories: 19,769 test vectors passed with zero failures and 11,302 were skipped with logged reasons, in 1,014 seconds on one machine. The vectors test the open-source libraries QNSQY ships. 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. CISA, NSA and NIST warn that adversaries could be collecting encrypted data today for this purpose. 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.

108 tools in the current release (52 on Free, 83 on Pro, all 108 on Business), 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. Your plan is set at run time by our billing server, which signs it. No setting in the downloaded program, and no rebuild of it, unlocks a higher plan.

At each successful check-in with the billing server, QNSQY saves your paid plan on the machine, and the saved plan stays valid for 7 days after the last check-in. It is bound to the machine and your API key, so a copy will not work on another machine. If 7 days pass without a check-in, QNSQY applies the Free plan until it checks in again. That includes opening files: in the current release a file made on a paid plan opens only on that plan or a higher one, so a machine that must open such files should check in at least once every 7 days.

In the current release, each file records the plan of the account that made it, and QNSQY opens it only on that plan or a higher one: a file made on Pro opens on Pro or Business, a file made on Business only on Business, and a file made on Free, or while signed out, on every plan. So when a paid plan ends, the files you made on it cannot be opened until you renew. QNSQY does not delete or change them. Before a plan ends, decrypt the files you will still need. If they must stay encrypted, encrypt them again while signed out, which uses the Free algorithms.

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.

Under NSA's CNSA 2.0 and CNSSP 15, all new national security system acquisitions must be CNSA 2.0 compliant from 1 January 2027, unless otherwise noted, and the CNSA 2.0 algorithms are mandated for use by 31 December 2031. Separately, NIST IR 8547 (draft) proposes deprecating quantum-vulnerable public-key algorithms such as RSA and elliptic-curve cryptography by 2030 and disallowing them by 2035. The CNSA 2.0 algorithms are ML-KEM-1024, ML-DSA-87, LMS and XMSS for software and firmware signing, AES-256 and SHA-384/512. QNSQY's Standard edition offers these except XMSS, among others; its CNSA 2.0 edition (not released) is limited to ML-KEM-1024, ML-DSA-87, AES-256-GCM and SHA-384/512 and has no NSA, NIAP or CSfC approval.

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 builds are on the roadmap, together with Apple code signing and notarization. Today QNSQY ships for Linux x86-64 and ARM64 (glibc 2.28 or newer, or the static build) and Windows 10 and 11.

Not yet. All reviews to date are internal. An independent third-party cryptographic code audit is in the use-of-funds plan.

Linux x86_64 with glibc 2.28 or later: the RHEL 8 and 9 families (Red Hat UBI 8 and 9, AlmaLinux 8 and 9, Rocky Linux 8 and 9, Oracle Linux 8 and 9, CentOS Stream 9); AlmaLinux 10; Amazon Linux 2023; Fedora 40, 41, 42, 43, 44; Ubuntu 20.04, 22.04, 24.04; Debian 11, 12 and 13 (trixie); openSUSE Leap 15.6 and SUSE Linux Enterprise 15 SP6. Not supported on older glibc: Ubuntu 18.04, RHEL and CentOS 7, Amazon Linux 2. The binary is built against the glibc 2.28 baseline. ARM64: .deb and .rpm packages built for ARM64, tested on ARM64 cloud servers in AlmaLinux 8, 9 and 10, Amazon Linux 2023, Fedora 44, Debian 11, 12 and 13, Ubuntu 20.04, 22.04 and 24.04, openSUSE Leap 15.6 and SUSE Linux Enterprise 15 SP6 containers on one Ubuntu 24.04 kernel; not yet on ARM64 desktops. Without glibc (Alpine): the static build, without the desktop app.