Approved-Mode and CNSA 2.0 Builds

Approved algorithms only. The choice is fixed when the program is built: no flag, setting or license can switch it off. Before first use, the program runs start-up self-tests, and it runs a pairwise consistency test on every ML-KEM and ML-DSA key pair it generates. It keeps its own state folder, never shared with the standard build.

Like the standard build, it signs in to our billing server for its license, and the server decides the tier. The desktop app and the terminal app are included; the MCP server for AI agents is refused.

The same approved-mode build, narrowed to the CNSA 2.0 algorithms: ML-KEM-1024, ML-DSA-87, AES-256-GCM and SHA-384/SHA-512. It is for defense and national-security users. Every encrypted item is signed with ML-DSA-87, and opening it requires the sender's public key. It uses an offline license and no network. The desktop app and the terminal app are included.

It carries no NSA, NIAP or CSfC approval.

Not FIPS 140-3 validated; no lab has tested QNSQY. On Linux, QNSQY compiles part of the AWS-LC FIPS 3.1.0 source (through the aws-lc-fips-sys crate) and runs SHA-2, SHA3-256, HMAC, HKDF, PBKDF2, AES-GCM, AES key wrap, ML-KEM, Ed25519 verification and random number generation in it. CMVP certificate #5314 covers that module only when built by its Security Policy's procedure on its tested systems (Amazon Linux 2023 on AWS Graviton4 and Intel Xeon Platinum 8375C); this build is neither. The module's own approval indicator does not count AES-GCM encryption with a nonce from outside the module, or PBKDF2 with a password under 14 bytes, as approved; QNSQY's files are encrypted with nonces made outside the module, and QNSQY accepts shorter passwords. ML-DSA and all Windows cryptography run in QNSQY's own code. QNSQY's own code around the module (file format, key handling, sandbox) is covered by no certificate.

• Approved algorithms only, fixed when the program is built; no flag, setting or license can switch it off.
• ML-KEM-512/768/1024 (FIPS 203), ML-DSA-44/65/87 (FIPS 204, hedged signing), AES-256-GCM, SHA-256/384/512 (SHA-512 default), SHA3-256 for the hash command, HMAC-SHA-512 and PBKDF2-HMAC-SHA-512.
• Refused: X25519/Ed25519 hybrids, HQC, SLH-DSA, FN-DSA, LMS, XChaCha20-Poly1305, BLAKE2/BLAKE3, Argon2id, and the vault, steganography, time-lock, threshold, deniable, polyglot, keyfile, escrow and MCP server features. They stay in the standard build.
• Start-up self-tests before first use (known-answer tests and a software integrity test); any failure means exit code 70 and no output.
• Pairwise consistency test on every generated ML-KEM and ML-DSA key pair.
• SP 800-90A random bit generator: AWS-LC's CTR_DRBG on Linux, QNSQY's own HMAC_DRBG with SHA-512 on Windows.
• An "Approved service" line for every operation, and a second line when the license check, a service that is not approved, ran.
• A zeroize command that overwrites and removes the build's stored state.
• Its own state folder, never shared with the standard build.
• Private keys at rest always passphrase-protected; unprotected keys are refused.
• Header tamper protection: a keyed MAC over the header, including the key-encapsulation block, and strict checks of reserved header bytes.
• Optional size sealing, and a text (ASCII) form of protected data.
• CMS and S/MIME: signing checked with OpenSSL; encryption checked against published examples only, not yet against another implementation.
• Data inventory: scan, migrate, audit, the OMB M-23-02 nine-item inventory report (CSV, XLSX, JSON), RPM package detection (on Windows: in development), and flags on algorithms that are not FIPS-approved.
• Desktop app and terminal app; the MCP server is refused.
• License through the billing server sign-in, like the standard build; the server decides the tier.
• Linux x86-64 and Windows x64 (Windows test limits under Platforms).
• On Windows, a firewall rule that blocks only QNSQY's own outbound traffic while an operation runs (when run with administrator rights).
• On Linux, part of the cryptography runs in the AWS-LC FIPS module, with the limits stated above.

• ML-KEM-1024, ML-DSA-87, AES-256-GCM and SHA-384/SHA-512 only; no SHA-3, no passwords.
• Every encrypted item signed with ML-DSA-87; the signature is checked before any plaintext is written.
• Offline license signed with ML-DSA-87 and bound to one device; decrypt and verify keep working after it expires.
• No network use: on Linux a seccomp filter ends the process if it tries to use a network socket; on Windows there is no network code path.
• X.509 trust anchors, with no revocation checking (offline).
• Signed audit trail: a SHA-512 hash chain signed with ML-DSA-87 that cannot be reset.
• Desktop app and terminal app.
• A status line that says what the build is and is not (quoted above).

It carries no NSA, NIAP or CSfC approval.

From the same work. These are also in the standard build and come with its next release.

• Safer folder decryption: a protected folder is restored only when it was protected as a folder, and links and paths that escape the target are refused.
• Strict header checks; the header MAC also covers the key-encapsulation block.
• Optional size sealing, and a text (ASCII) form.
• Export to standard formats: CMS, S/MIME, age and JWE with post-quantum keys, tested against published test vectors; interoperability with other tools is not yet tested.
• The OMB M-23-02 nine-item inventory report, also in the desktop app, terminal app and MCP server; RPM package detection (on Windows: in development); a flag for algorithms that are not FIPS-approved.
• Hedged ML-DSA signing.
• Linux sandbox: an extra guard against the x32 system-call route.