Three Editions of QNSQY
One code base, three builds. The Standard edition is available now. The Approved Mode and CNSA 2.0 editions are built and tested internally and not released yet. This page says what each one is, what it does, which standards it follows, and what it is not.
The three editions
Standard
For people and organizations that want post-quantum protection for files, folders, backups and archives. Hybrid post-quantum key exchange by default and every algorithm QNSQY offers. Free, Pro and Business plans. Linux and Windows.
Approved Mode
For organizations that must use FIPS-approved algorithms only, ahead of a FIPS 140-3 validation. The choice is fixed when the program is built. Start-up self-tests, an error state, key-pair checks, an SP 800-90A random bit generator and an "Approved service" line for every operation.
CNSA 2.0
For defense and national-security users. The Approved Mode edition narrowed to NSA's CNSA 2.0 algorithms: ML-KEM-1024, ML-DSA-87, AES-256 and SHA-384/512. An offline licence, no network use, every file signed, a Crypto Officer role and a signed audit trail that cannot be switched off.
Not certified.
None of the three editions is FIPS 140-3 validated. QNSQY holds no CMVP certificate, and no lab has tested it. The CNSA 2.0 edition has no NSA, NIAP or CSfC approval. Our test results are evidence, not certification: Validation, Certifications.
Side by side
| Standard | Approved Mode | CNSA 2.0 | |
|---|---|---|---|
| Status | Available now; current release on the download page | Built and tested internally. Not yet released. | Built and tested internally. Not yet released. |
| How you get it | Download page, apt and dnf repositories, npm | On request; contact us | On request, as an offline install kit; contact us |
| Plan and licence | Free, Pro and Business plans, set online by our billing server | Plan set online by our billing server, as in the Standard edition | Offline licence file, signed with ML-DSA-87 and bound to one device; no account, no sign-in |
| Network use | A short billing check-in; the Linux command line then blocks every network call before any cryptographic work | Same as the Standard edition | None. On Linux a kernel filter ends the process if it tries to use a network socket; the Windows build has no network code path |
| Key exchange | ML-KEM-512, -768 and -1024 with X25519 (hybrid, the default); pure ML-KEM and HQC on Business | ML-KEM-512, -768 and -1024 (pure), to recipient keys | ML-KEM-1024 only |
| Signatures | ML-DSA-44, -65 and -87 (pure by default; hybrid with Ed25519 on Pro and Business), SLH-DSA, FN-DSA (pre-standard), LMS | ML-DSA-44, -65 and -87 (pure, hedged) | ML-DSA-87 only (pure, hedged); every encrypted file is signed, and the signature is checked before any plaintext is written |
| Encryption | AES-256-GCM (default) or XChaCha20-Poly1305 | AES-256-GCM | AES-256-GCM |
| Hashing | SHA3-256 and BLAKE3 by default; a SHA-512 profile per file | Files: SHA-512 profile only. Hash command: SHA-256, SHA-384, SHA-512 (default) or SHA3-256 | SHA-384 and SHA-512 only |
| Password-based keys | Argon2id | PBKDF2-HMAC-SHA-512, 600,000 iterations | PBKDF2-HMAC-SHA-512 for private keys at rest; password-protected files are refused |
| Random numbers | The operating system's generator | An SP 800-90A generator: in the AWS-LC module on Linux, QNSQY's own HMAC_DRBG (SHA-512) on Windows | Same as Approved Mode |
| Start-up checks | The program checks a hash of itself (tamper detection) | Known-answer self-tests and a software integrity test before any service; any failure stops every command (exit code 70, no output) | Same as Approved Mode |
| Features | All of them, including vault, Shamir sharing, threshold, steganography, time-lock, deniable containers, polyglot files, attribute-based encryption, remote backup and migration | Approved functions only: encrypt, decrypt, sign, verify, hash, key generation, scan, migrate, audit, shred. Refused: vault, steganography, time-lock, threshold, deniable, polyglot, keyfile, escrow, remote backup | As Approved Mode, without sign-in or password files; adds the licence and Crypto Officer commands |
| Operator authentication | Account sign-in | Account sign-in | A Crypto Officer role, with a secret of at least 16 characters, checked on every run |
| Audit trail | Encrypted, hash-chained log on every plan; ML-DSA-signed chain on Business | Same; a signed trail can be switched on (one way) | Always on: signed with ML-DSA-87, cannot be switched off or reset; security events also go to the operating system's log |
| X.509 certificates | No | Optional, from your own ML-DSA-87 certificate authority | Yes, with revocation lists (no OCSP) |
| Interfaces | Command line, desktop app, terminal app, MCP server for AI agents | Same four; the MCP server offers only the tools of approved commands | Same four; the MCP server runs only tools that need no Crypto Officer secret |
| Platforms | Linux x86-64 (.deb, .rpm), Windows 10 and 11 x64 | Linux x86-64, Windows x64 (Windows tested in a Windows 11 virtual machine) | Same as Approved Mode |
| Certified module inside | None | On Linux part of the cryptography runs in the AWS-LC FIPS 3.1.0 module; its CMVP certificates (#5314, #5298) do not cover this build | Same as Approved Mode; ML-DSA runs in QNSQY's own code on every platform |
| Certification | None | Not FIPS 140-3 validated | Not FIPS 140-3 validated; no NSA, NIAP or CSfC approval |
Standards each edition follows
Each entry links to the official document. "Yes" means the edition implements that standard's algorithm or format; it does not mean a lab has tested or certified it.
| Standard | Standard | Approved Mode | CNSA 2.0 |
|---|---|---|---|
| FIPS 203 ML-KEM | Yes | Yes | Yes (ML-KEM-1024) |
| FIPS 204 ML-DSA | Yes | Yes | Yes (ML-DSA-87) |
| FIPS 205 SLH-DSA | Yes | No | No |
| SP 800-208 LMS | Yes | No | No |
| FN-DSA (FIPS 206, not yet published) and HQC (selected by NIST, not yet a standard) | Yes (pre-standard) | No | No |
| FIPS 197 AES and SP 800-38D GCM | Yes | Yes | Yes |
| FIPS 180-4 SHA-2 | Yes (SHA-512 profile) | Yes | Yes (SHA-384, SHA-512) |
| FIPS 202 SHA-3 | Yes | Yes (hash command) | Only inside ML-KEM and ML-DSA |
| FIPS 198-1 HMAC | Yes | Yes | Yes |
| HKDF: RFC 5869; SP 800-56C Rev. 2 | Yes | Yes (HKDF-SHA-512) | Yes (HKDF-SHA-512) |
| SP 800-132 PBKDF2 | Opens Approved Mode password files | Yes | Yes |
| SP 800-90A Rev. 1 random bit generators | No | Yes | Yes |
| RFC 9106 Argon2id | Yes | No | No |
| RFC 7748 X25519 and RFC 8032 Ed25519 for your data | Yes (in hybrids) | No | No |
| RFC 8439 ChaCha20-Poly1305 (XChaCha20 variant) | Yes | No | No |
| FIPS 140-3 | No | Design target; not validated | Design target; not validated |
| NSA CNSA 2.0 algorithm suite | No | No | Yes (algorithms only; no NSA approval) |
| CMS and S/MIME with ML-KEM: RFC 9629, RFC 9936, RFC 8551 | Yes | Yes | Yes |
| RFC 5280 X.509 certificates and revocation lists | No | Optional | Yes |
| OMB M-23-02 inventory report | Yes | Yes | Yes |
| CycloneDX 1.6 cryptography bill of materials from the scan | Yes | Yes | Yes |
Which one fits
- Standard: for most people and organizations. It offers the widest choice of post-quantum algorithms, hybrid with classical ones by default.
- Approved Mode: when your policy requires FIPS-approved algorithms. It is not FIPS 140-3 validated, so it does not meet a requirement for a validated module.
- CNSA 2.0: for national security systems that must move to the CNSA 2.0 algorithms. NSA states that products used in national security systems also need NIAP or NSA validation (CNSSP 11); QNSQY has neither.
For availability and pricing of the Approved Mode and CNSA 2.0 editions, contact us. There is no release date yet.