Download QNSQY

One command installs both CLI and GUI. All cryptographic operations run locally and your data never leaves the machine. Password encryption, ML-KEM-512 and ML-DSA-44 work offline without an account; paid plans check in with our billing server to validate the subscription.

These downloads are the Standard edition, version 7.2.46. The Approved Mode and CNSA 2.0 editions are built and tested internally and not released; they are not public downloads. Compare the three editions.

19,769 / 0 NIST ACVP vectors pass / fail (7.2.41 sweep)
v7.2.47 Latest Version
Oct 14, 2026 Released

Free Version

Personal use. Quantum-safe encryption. ML-KEM-512 + ML-DSA-44, unlimited, with no file-size limit on the command line (the desktop app stops at 100 MB per file on Free).

Linux

x86_64 · ARM64 · glibc 2.28+

Tested in October 2026 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 and openSUSE Leap 15.6 / SUSE Linux Enterprise 15 SP6 (the SLES BCI image). On each, in a clean container, we installed it three ways (the package manager with signature checks on, the one-line installer, the bare program) and ran a password encrypt and decrypt round trip, a hash and the terminal app, with no network and the network lock on. The kernels of AlmaLinux 8 and 9 (RHEL 8 and 9 rebuilds) were also checked in virtual machines: the network lock applies on both; the AlmaLinux 8 kernel (4.18, as in RHEL 8) has no Landlock, so there QNSQY runs without its file-access limits. The desktop app was checked on AlmaLinux 8 and 9, under Wayland and X11, with the libraries a desktop installation has (on X11 it opens only with --allow-x11, see security). Earlier: with 7.2.18 we ran the Free-tier suite (ML-KEM-512 recipient round-trip, ML-DSA-44 sign/verify, AES-256-GCM password round-trip, BLAKE3 hash) and the Business-tier suite (FN-DSA-1024, HQC-256, LMS-SHA256-H10W2, SLH-DSA-128s, ML-KEM-1024) on each distribution then supported; the re-check with the shipped 7.2.39 program gave identical output on 18 distributions. Not supported: glibc older than 2.28 (Ubuntu 18.04, RHEL and CentOS 7, Amazon Linux 2).

ARM64 (aarch64), tested on ARM64 cloud servers (Arm Neoverse-N2) in October 2026. The ARM64 .deb and .rpm packages need glibc 2.28 or newer, as on x86_64. On those servers, in containers of 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 (all on the servers' Ubuntu 24.04 kernel), it installed through the package manager with signature checks on and through the one-line installer, and passed a password encrypt and decrypt round trip, a hash and the terminal app with the network lock on. On the servers' own Ubuntu 24.04 (kernel 6.17) the file-access limits (Landlock) apply too; there the program checked both release lists' ML-DSA-87 signatures and refused a changed list and a changed signature, and files encrypted on x86_64 decrypted on ARM64 and the other way round. The desktop app opened its window on X11 and on Wayland, on a virtual display (AlmaLinux 9 and Ubuntu 24.04); it has not been tried on an ARM64 desktop. In emulated ARM64 machines, Debian 11 (kernel 5.10) and Debian 12 (kernel 6.1) passed the round trip, the hash, the terminal app and the MCP server with the network lock on; the Debian 11 kernel has no Landlock, so there QNSQY runs without the file-access limits. The known-answer tests of ML-KEM, ML-DSA, SLH-DSA, FN-DSA, HQC and LMS pass on ARM64 (in emulation) with the same results as on x86_64.

Static build (x86_64 and ARM64), for Alpine Linux and other systems without glibc. One program with the command line, the terminal app (qnsqy --tui) and the MCP server (qnsqy --mcp). No desktop app: a static program cannot load the desktop libraries. The x86_64 build passed the same checks, network lock included, on Alpine Linux 3.24 and Fedora 44, and in Debian 12, AlmaLinux 8, openSUSE Leap 15.6 and Ubuntu 20.04 containers. The ARM64 build passed them on ARM64 cloud servers, in an Alpine Linux 3.24 container and on the servers' Ubuntu 24.04 (where it reports Landlock fully enforced), and in emulated ARM64 machines with Debian 11 and 12.

Quick Install (Recommended)

Installs both CLI and GUI. After install: qnsqy or qnsqy-gui

curl -fsSL https://quantumsequrity.com/downloads/install.sh | bash

Manual Download (x86_64)

Single unified binary includes CLI, GUI, TUI, and MCP server

↓ RPM (RHEL/Fedora/SUSE) 15 MB ↓ DEB (Ubuntu/Debian) 14 MB

Manual Download (ARM64)

Tested on ARM64 cloud servers, not yet on ARM64 desktops. The same program as x86_64; the desktop app ran only on a virtual display

↓ RPM (RHEL/Amazon Linux/SUSE) 15 MB ↓ DEB (Ubuntu/Debian) 12 MB

Static Build (no desktop app)

For Alpine and other systems without glibc: CLI, TUI and MCP server

↓ x86_64 (.tar.gz) 6 MB ↓ ARM64 (.tar.gz) 6 MB

macOS

Not available yet

There is no macOS build yet, and no release date. Join the waitlist to be notified when one is ready.

Windows

x86_64 · Windows 10 1809+ / 11

Tested under Wine in Windows 10 and Windows 11 modes (11/11 free-tier tests, with 7.2.18); the 7.2.45 release candidate also ran in a Windows 11 virtual machine, as a standard user and as an administrator. Add --acknowledge-no-sandbox to commands that require network isolation acknowledgment.

Installer (Recommended)

NSIS installer registers in Add/Remove Programs and adds Start Menu entries.

↓ qnsqy-setup-7.2.47.exe 21 MB

Portable Binary

Single .exe, no install. Run from any folder or USB stick.

↓ qnsqy-7.2.47-x86_64.exe 54 MB

Note: Windows cannot enforce kernel-level network sandboxing the way Linux seccomp does; run as administrator, QNSQY adds an outbound Windows Firewall block for itself during each cryptographic operation, and as a standard user no block is enforced. The crypto itself is unchanged, but the "file content never leaves the machine" guarantee relies on the binary's good behavior, not a kernel block. For air-gapped use cases, the Linux build is recommended. See Security for details.

SHA-256 Checksums (v7.2.47)

# Linux
6a96747a437eb0bf471504363c0393cbeae9244b2d825e407c3da11d45b147a8  qnsqy-7.2.47-1.x86_64.rpm
86092578401604091ca9f0cc6f5dc6574ce8686fe49f7831d95ee32061d7a7c0  qnsqy_7.2.47-1_amd64.deb

# Linux ARM64
b99cde32ee4b675860954b0ca9c06c5826f1b2297b73b3449dd394be8cc1b00a  qnsqy-7.2.47-1.aarch64.rpm
f0533452db6d5b7e7a263192ed9cdad12a7bf04cfd81fcad7313feec81f8ab02  qnsqy_7.2.47-1_arm64.deb

# Linux static build (no desktop app)
275070e76a4ff7ba634cb2db627491b0b23d5dd1d41ceb5712d07a5b711a305c  qnsqy-7.2.47-linux-x86_64-static.tar.gz
2216cfb855771c705952091b7251ca07222215e78f198fdf4022100da0a5bcca  qnsqy-7.2.47-linux-aarch64-static.tar.gz

# Windows
b2995b3776797ac9ea6783d9ccc4e0d6c39defed28f6844b6d97ce7eab684337  qnsqy-setup-7.2.47.exe
b17b0c59af29af3fb313d93ead16e30c68a70ed0d7122402610ce66db314d799  qnsqy-7.2.47-x86_64.exe

# Verify the checksums file itself with the signed checksums.txt.sig
# (ML-DSA-87 / NIST FIPS 204 / post-quantum, security level 5).
# QNSQY embeds the current release public key (BLAKE3 fingerprint
# 50af23b47dca8d74), so verify-release works with no extra flags.
# curl -LO https://cdn.quantumsequrity.com/linux/checksums.txt
# curl -LO https://cdn.quantumsequrity.com/linux/checksums.txt.sig
# qnsqy verify-release checksums.txt checksums.txt.sig

Installation Guide

Install via RPM (dnf), DEB (apt), npm (npm install -g qnsqy), or download a standalone binary. No root access required for binary installs.

One Unified Binary

QNSQY ships as a single unified binary (~47 MB) that includes CLI, GUI, TUI, and MCP server. Run mode is detected automatically:

qnsqyCLI mode (default)
qnsqy --guiLaunch desktop GUI
qnsqy --tuiTerminal UI
qnsqy --mcpMCP server (JSON-RPC)

Or create symlinks: qnsqy-gui / qnsqy-tui / qnsqy-mcp for mode auto-detection.

Linux - Package Managers

# Ubuntu / Debian (APT repository)
$ curl -fsSL https://cdn.quantumsequrity.com/repo/qnsqy-repo.gpg.asc | sudo gpg --dearmor -o /usr/share/keyrings/qnsqy.gpg
$ echo "deb [signed-by=/usr/share/keyrings/qnsqy.gpg] https://cdn.quantumsequrity.com/repo/deb stable main" | sudo tee /etc/apt/sources.list.d/qnsqy.list
$ sudo apt update && sudo apt install qnsqy

# RHEL 8+ and its rebuilds, Amazon Linux 2023, Fedora (DNF repository)
$ sudo tee /etc/yum.repos.d/qnsqy.repo <<'EOF'
[qnsqy]
name=QNSQY
baseurl=https://cdn.quantumsequrity.com/repo/rpm
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://cdn.quantumsequrity.com/repo/qnsqy-repo.gpg.asc
EOF
$ sudo dnf install qnsqy

# openSUSE Leap 15.6 / SLES 15 SP6 (zypper repository)
$ sudo zypper addrepo https://cdn.quantumsequrity.com/repo/rpm/qnsqy.repo
$ sudo zypper install qnsqy

# npm (wrapper package, installs the same binary)
$ npm install -g qnsqy

# Verify installation
$ qnsqy version
QNSQY v7.2.47
Tier: Free

The repositories are signed. The key at qnsqy-repo.gpg.asc is RSA-4096, fingerprint 127B 9C49 8A44 09CB 7E76 8F2B 3E4E C494 939D 0A89; dnf and zypper show the fingerprint before they import the key, so compare it. If you added the DNF repository earlier, dnf asks to import this key on your next upgrade. APT needs no change: its index is signed by both this key and the Ed25519 key C8BE B5E1 75D4 493B 6067 8BB8 E76B B1B3 9C41 D8B6. The Ed25519 key, which signed the earlier rpm packages, is now at qnsqy-repo-ed25519.gpg.asc. On ARM64 the same commands install the ARM64 package.

Linux - Manual Package Install

# RHEL 8+, Amazon Linux 2023, Fedora (RPM)
$ curl -fsSLO https://cdn.quantumsequrity.com/linux/qnsqy-7.2.47-1.x86_64.rpm
$ sudo dnf install ./qnsqy-7.2.47-1.x86_64.rpm

# Ubuntu / Debian (DEB)
$ curl -fsSLO https://cdn.quantumsequrity.com/linux/qnsqy_7.2.47-1_amd64.deb
$ sudo apt install ./qnsqy_7.2.47-1_amd64.deb

# ARM64: the same commands with the ARM64 files
$ curl -fsSLO https://cdn.quantumsequrity.com/linux/qnsqy-7.2.47-1.aarch64.rpm
$ sudo dnf install ./qnsqy-7.2.47-1.aarch64.rpm
$ curl -fsSLO https://cdn.quantumsequrity.com/linux/qnsqy_7.2.47-1_arm64.deb
$ sudo apt install ./qnsqy_7.2.47-1_arm64.deb

# Static build, for Alpine and other systems without glibc (ARM64: linux-aarch64-static)
$ curl -fsSLO https://cdn.quantumsequrity.com/linux/qnsqy-7.2.47-linux-x86_64-static.tar.gz
$ tar -xzf qnsqy-7.2.47-linux-x86_64-static.tar.gz
$ sudo install -m 755 qnsqy-7.2.47-linux-x86_64-static/qnsqy /usr/local/bin/qnsqy

# Verify installation
$ qnsqy version
QNSQY v7.2.47
Tier: Free

# Encrypt your first file
$ qnsqy encrypt -i secret.pdf

Windows / macOS

# Windows builds are available above (installer + portable .exe).
# There is no macOS build yet.
# Join the waitlist above to be notified when macOS is ready.

Linux - GUI Mode

# After installing, launch GUI mode:
$ qnsqy --gui

# Or add a qnsqy-gui shortcut: run under that name, QNSQY opens the desktop app
$ mkdir -p ~/.local/bin && ln -s /usr/bin/qnsqy ~/.local/bin/qnsqy-gui
$ qnsqy-gui

# TUI (Terminal UI) mode:
$ qnsqy --tui

Quick Start

# Encrypt a file (creates secret.pdf.qs); nothing shows while you type the password
$ qnsqy encrypt -i secret.pdf
Password:
Confirm password:
Encrypted to: secret.pdf.qs

# Decrypt to a new name (QNSQY never overwrites a file unless you add -f)
$ qnsqy decrypt -i secret.pdf.qs -o secret-restored.pdf
Password:
Decrypted to: secret-restored.pdf

# Securely delete the original (on an SSD, QNSQY first warns and asks again)
$ qnsqy shred secret.pdf
This will PERMANENTLY and IRRECOVERABLY delete:
  secret.pdf
Are you sure? [y/N] y
Shredding with 3 passes...
Securely deleted: secret.pdf

# On Linux you will also see SECURITY| lines: the sandbox reporting that it is on.
Full Documentation

Verify Your Download

Always verify a download before installing. Every QNSQY release can be checked three independent ways (a SHA-256 checksum and two signatures), so you can prove the binary is exactly what we published. Use any one of them; using more raises the bar an attacker would have to clear.

1. SHA-256 checksum (fastest)

Compare the hash of your file against the SHA-256 list published above.

# Linux (RPM, DEB or the static tarball; the ARM64 files the same way)
$ sha256sum qnsqy-7.2.47-1.x86_64.rpm
$ sha256sum qnsqy_7.2.47-1_amd64.deb
$ sha256sum qnsqy-7.2.47-linux-x86_64-static.tar.gz

# Windows (PowerShell or cmd)
PS> Get-FileHash qnsqy-7.2.47-x86_64.exe -Algorithm SHA256
> certutil -hashfile qnsqy-7.2.47-x86_64.exe SHA256

# The output must match a checksum published above. If it does not, do not run it. Re-download.

2. Post-quantum ML-DSA-87 release signature

Every release ships a checksums.txt manifest signed with our ML-DSA-87 release key (NIST FIPS 204, post-quantum security level 5). The verification key is embedded in every QNSQY binary (BLAKE3 fingerprint 50af23b47dca8d74) and is also published at quantumsequrity.com/keys/release-mldsa87.pub.

# Download the signed manifest
$ curl -LO https://quantumsequrity.com/downloads/checksums.txt
$ curl -LO https://quantumsequrity.com/downloads/checksums.txt.sig

# Verify it with the key embedded in any QNSQY install
$ qnsqy verify-release checksums.txt checksums.txt.sig
RELEASE_SIGNATURE_OK

# Then confirm your download's SHA-256 appears in the verified manifest.

3. Sigstore / cosign transparency log

The 7.2.45 manifest on this site is also signed with Sigstore (cosign, keyless: a short-lived certificate tied to our public GitHub build workflow), and the signature is recorded in the public Rekor transparency log. It is a separate signature that does not use the ML-DSA-87 key.

# Install cosign once, then:
$ curl -LO https://quantumsequrity.com/downloads/checksums.txt
$ curl -LO https://quantumsequrity.com/downloads/checksums.txt.cosign.sig
$ curl -LO https://quantumsequrity.com/downloads/checksums.txt.cosign.pem
$ cosign verify-blob \
    --certificate-identity-regexp 'https://github.com/quantumsequrity/qnsqy/\.github/workflows/sign-release\.yml@.*' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    --signature checksums.txt.cosign.sig \
    --certificate checksums.txt.cosign.pem \
    checksums.txt
Verified OK

Installing through the apt or dnf repository adds another check automatically: the repository metadata is GPG-signed (repo_gpgcheck=1) and pins each package's SHA-256, and dnf also checks each package's own signature (gpgcheck=1), so your package manager verifies authenticity on every install and update without any extra steps. If you added the dnf repository before 18 October 2026, turn on the package check once: sudo sed -i 's/^gpgcheck=0/gpgcheck=1/' /etc/yum.repos.d/qnsqy.repo.

Software Bill of Materials (SBOM)

Every release since 7.2.41 ships a software bill of materials for QNSQY in CycloneDX JSON: qnsqy-7.2.47.cdx.json. It lists every dependency in the release's Rust lock file (Cargo.lock), with its version, package URL and, for crates.io crates, the SHA-256 recorded in the lock file, and how the dependencies depend on each other. It is a superset of what any one binary contains: the lock file also lists crates used only for tests or only on another platform. It covers the Rust dependencies only: system libraries the binary uses at run time, such as the C library on Linux and the Windows system DLLs, are not listed. The SBOM is listed in the signed checksums.txt, so the ML-DSA-87 and Sigstore signatures above cover it too. 

$ curl -LO https://quantumsequrity.com/downloads/qnsqy-7.2.47.cdx.json
$ sha256sum qnsqy-7.2.47.cdx.json

# The hash must match the qnsqy-7.2.47.cdx.json line of checksums.txt,
# after you verify checksums.txt as shown above.

If Windows warns you

On a fresh download, Windows SmartScreen may show a blue dialog: "Windows protected your PC. Microsoft Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk. Unknown publisher." This is expected: the 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, as shown here.

Why SmartScreen shows "Unknown Publisher"

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. Unlike Authenticode, which uses RSA or ECDSA, ML-DSA-87 is designed to resist quantum attacks; but Windows does not check it for you. Windows does not yet natively verify post-quantum signatures, so SmartScreen treats the publisher as unknown.

A Microsoft Authenticode certificate from an EV CA 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 believe shipping real post-quantum signatures today matters more than waiting on a legacy certificate path.

Two ways to verify the binary on Windows

The hash check shows that the file matches the published list; the ML-DSA-87 check also proves that the list itself was signed with our release key. Running both is best. A third check, cosign / Sigstore, is shown under Verify Your Download above.

1. SHA-256 hash check

Compare the hash of your download to the official SHA-256 listed above. Windows ships two ways to do this out of the box.

# Command Prompt (cmd.exe)
> certutil -hashfile qnsqy.exe SHA256

# PowerShell
PS> Get-FileHash qnsqy.exe -Algorithm SHA256

# The output should match the SHA-256 published on this page.
# If it does not match, do not run the binary. Re-download.

2. Post-quantum ML-DSA-87 release signature

Every release publishes a checksums.txt manifest signed with our ML-DSA-87 release key (NIST FIPS 204). The verification key is embedded in every QNSQY binary (BLAKE3 fingerprint 50af23b47dca8d74), and the same public key is published at quantumsequrity.com/keys/release-mldsa87.pub. If you already have any QNSQY install on any platform, verify the signed manifest, then check your download's hash against it. 

# 1. Download the signed checksums manifest
$ curl -LO https://quantumsequrity.com/downloads/checksums.txt
$ curl -LO https://quantumsequrity.com/downloads/checksums.txt.sig

# 2. Verify the manifest signature with the key embedded in the binary
$ qnsqy verify-release checksums.txt checksums.txt.sig
Using embedded release public key (BLAKE3 fingerprint: 50af23b47dca8d74)
RELEASE_SIGNATURE_OK

# Or verify against the published key instead of the embedded one:
$ curl -LO https://quantumsequrity.com/keys/release-mldsa87.pub
$ qnsqy verify-release checksums.txt checksums.txt.sig --pubkey @release-mldsa87.pub

# 3. Check your download's SHA-256 against the verified manifest
> certutil -hashfile qnsqy.exe SHA256
# The hash must match the qnsqy.exe line in checksums.txt.

Once you have verified it: how to run past SmartScreen

After you have confirmed the binary is authentic using any method above, here is how to launch it.

  1. Double-click qnsqy.exe. The blue SmartScreen dialog appears.
  2. Click the small "More info" link in the dialog. A new line appears showing the app name and publisher (Unknown).
  3. Click the "Run anyway" button that has now appeared at the bottom right.
  4. The app starts. Windows remembers your choice for this binary, so SmartScreen will not warn again for this exact file.

If your IT policy disables "Run anyway" entirely, ask your administrator to allowlist the SHA-256 hash published above. The binary's integrity is provable from the hash alone.

System Requirements

Windows

10 / 11

64-bit (x64) required

macOS

Not yet

No ship date. Linux + Windows only.

Linux

glibc 2.28+

RHEL 8+ (and AlmaLinux, Rocky, Oracle Linux), Amazon Linux 2023, Fedora 40+, Ubuntu 20.04+, Debian 11+, SLES 15 SP6. ARM64: tested on ARM64 cloud servers, not yet on ARM64 desktops (installs and checks 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 SLES 15 SP6 containers on one Ubuntu 24.04 kernel). Without glibc (Alpine): the static build, no desktop app

Memory

256 MB

More recommended for large files

Disk Space

50 MB

Plus space for encrypted files

Network

Optional

All cryptographic operations run locally; data never leaves the machine. Password encryption, ML-KEM-512 and ML-DSA-44 work offline without an account; paid plans check in with our billing server (cached for up to 7 days). A fully offline edition (CNSA 2.0: offline licence, no network use) is built and tested internally and not yet released; contact us.

Not available yet

Platforms and package managers we do not offer yet (no release dates):

FreeBSD Homebrew (macOS) AUR (Arch Linux) Snap Flatpak Windows Package Manager (winget) Nix

Release notes

What changed in each release, newest first.

Not yet released: approved-mode and CNSA 2.0 builds

No release date yet

Not yet released
  • Built and tested internally. Not yet released. An approved-mode build that allows approved algorithms only and runs start-up self-tests before first use, and a CNSA 2.0 build narrowed to the CNSA 2.0 algorithms, with an offline license and no network use. Both ran on Windows 11 in a virtual machine (October 2026), as a standard user and as an administrator.
  • The changes from this work that apply to every edition are already in the standard build: they shipped with 7.2.44 and 7.2.45 (see those entries). What each edition allows and refuses: the three editions. What is in development and what is planned: the roadmap.
  • 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.

v7.2.47 Linux on ARM64 and a static Linux build; signature checks over the bytes decryption reads

October 24, 2026

Added
  • Linux on ARM64 (aarch64), tested in emulation, not yet on ARM64 hardware: .deb and .rpm packages for glibc 2.28 and newer, in the same apt, dnf and zypper repositories, and through npm. The packages installed with signature checks on in emulated AlmaLinux 8 and 9, Amazon Linux 2023, Debian 11, Ubuntu 20.04 and openSUSE Leap 15.6 containers. In emulated ARM64 machines with Debian 11 and 12 the program passed its checks with the network lock on; on Debian 12 also with the file-access limits, the check of a release signature, and files moved between x86_64 and ARM64 in both directions. The known-answer tests of ML-KEM, ML-DSA, SLH-DSA, FN-DSA, HQC and LMS pass on ARM64 with the same results as on x86_64. The desktop app has not been tested on ARM64.
  • A static Linux build for x86_64 and ARM64 (.tar.gz), for Alpine Linux and other systems without glibc (tested on Alpine Linux 3.24): the command line, the terminal app and the MCP server, without the desktop app.
  • The one-line installer picks the ARM64 package on ARM64. On a system without glibc, such as Alpine, it points to the static build, before it asks for any tool.
Security
  • decrypt --verify-key now checks a whole-file signature (QSG2 or QSIG) over exactly the bytes the decryption reads, before any output is kept. Before, someone who could change the file on disk during a decryption, and who could also encrypt to the recipient, could have the decryption read different data from the data the signature check had read. QSG3 signatures were already bound to what the decryption reads.

v7.2.46 RHEL 8 and 9, Amazon Linux 2023, Debian 11, Ubuntu 20.04 and SUSE; no file path in usage receipts

October 23, 2026

Added
  • Linux: the program now needs glibc 2.28 or newer, down from 2.35. That adds the RHEL 8 and 9 families (tested on Red Hat UBI 8 and 9, AlmaLinux, Rocky Linux and Oracle Linux 8 and 9, and CentOS Stream 9), Amazon Linux 2023, Debian 11, Ubuntu 20.04, openSUSE Leap 15.6 and SUSE Linux Enterprise 15 SP6 to the Fedora, Ubuntu, Debian and AlmaLinux 10 releases supported before.
  • A zypper repository for openSUSE and SLES. The one-line installer works there too: it imports the repository key only after checking its fingerprint.
Changed
  • New rpm packages are signed with a new RSA-4096 repository key, fingerprint 127B 9C49 8A44 09CB 7E76 8F2B 3E4E C494 939D 0A89, because the rpm of RHEL 8 cannot read Ed25519 signatures. The key file at the old address, qnsqy-repo.gpg.asc, now holds this key, so the repository setup stays the same. If you added the DNF repository earlier, dnf asks to import the new key on your next upgrade. The Ed25519 key, which signed the earlier rpm packages, moved to qnsqy-repo-ed25519.gpg.asc. APT needs no change: its index is signed by both keys.
Fixed
  • Usage receipts no longer carry a hash of the file's path. A signed-in account's receipts sent the billing server an unkeyed hash of the path, which anyone holding the receipts could confirm by guessing the path. Billing stored it but never used it. The field is now always zero.

v7.2.45 Signature checks read the file being decrypted; faster decryption

October 14, 2026

Security
  • decrypt --verify-key now checks the signature of the file it is decrypting. Before, it read the file again by its name, so a file renamed or swapped during a decryption could have its signature checked on a different, validly signed file. The check before decryption and the re-check after it both read the decryption's own copy.
Changed
  • Faster decryption of files up to 64 MiB: the file's integrity tree (a Merkle tree) is hashed on other processor cores while the file decrypts. The tree is still checked before any output is kept.
  • This version can check the new signature format of the CNSA 2.0 edition (not released): one ML-DSA-87 signature over SHA-512 digests of the file in 1 MiB blocks. Versions 7.2.44 and earlier cannot check it.

v7.2.44 Standard formats with post-quantum keys, size sealing, MCP and verify-only fixes

October 13, 2026

Added
  • Encryption to standard formats with post-quantum keys: encrypt --carrier writes CMS or S/MIME for an ML-KEM recipient certificate, age for a post-quantum age recipient, or JWE. Checked against published test vectors; tests against other tools are still to come. Also in the desktop app and the terminal app.
  • A text form: --armor writes the encrypted file as ASCII text, for channels that carry text only. On the command line and in both apps.
  • Size sealing: encrypt --paranoid now hides the exact size of the data. The size travels inside the encrypted header, and random padding brings the encrypted data to a published bucket size, so the file length reveals only the bucket. In a sealed file the header check (MAC) also covers the key-encapsulation block. A sealed file opens only with 7.2.44 or later; earlier versions refuse it. Before, --paranoid added 5 to 15% random padding.
  • The OMB M-23-02 inventory report: the scan writes the memo's nine-item inventory of one system as CSV, Excel or JSON, and flags each algorithm that is not FIPS-approved. Also in the desktop app, the terminal app and the MCP server.
  • "Update now" notices: when a released version has a security problem, the apps of a signed-in Pro or Business account name the fixed version and link to the advisory. The notice comes only from the signed subscription token, and nothing stops working. Free accounts and use without an account get no notice.
  • Hedged ML-DSA signing: each signature includes fresh randomness.
  • Two editions for regulated settings, Approved Mode and CNSA 2.0, are built from the same source. They are not part of the standard downloads and are not released yet; see the three editions.
Security
  • decrypt --verify-only now checks every data chunk before it reports success. Before, it checked only the header, so a file with a changed data byte was reported as verified and failed only when decrypted. Our own fuzzing found it. If you checked backups with --verify-only on an earlier version, check them again with this one.
  • Linux sandbox: each QNSQY process also grants itself the files and folders named on its command line (inputs read-only, the output folder writable). Files outside the home and temporary folders, for example on another drive, now work with the sandbox on; before, they were refused with "Permission denied".
  • Linux sandbox: an extra guard against the x32 system-call route.
  • Folder decryption is safer: a file is unpacked as a folder only when it was encrypted as a folder, and links and paths that would escape the target folder are refused.
  • ML-KEM: before a private key is used to decrypt, it passes the FIPS 203 input check (the hash stored in the key must match its public part); a key that fails is refused.
  • HQC: the shared secret is wiped in place. Before, a copy was wiped and the original stayed in memory.
Fixed
  • MCP: qnsqy --mcp now uses the standard MCP stdio framing, one JSON message per line, so standard MCP clients get answers. Before, it used Content-Length framing only. That framing still works.
  • A decryption stopped by SIGTERM or SIGHUP (a kill, a service stop, a closed terminal) now removes its partial temporary file, as Ctrl+C already did. Temporary outputs are new hidden files next to the output and never take over an existing file. A stop that cannot be caught (kill -9, a power cut) can still leave the hidden temporary file behind.
  • Escrow: a file encrypted to a recipient key no longer gets an escrow block. That block could never recover such a file, yet said it could. Recipient-key files made by earlier versions still carry one: it cannot recover them, so keep the recipient's private key safe.
  • --password-stdin accepts a password piped from Windows PowerShell 5, which puts a byte-order mark in front of it.
  • status without an account names what works without one (password encryption, ML-KEM-512, ML-DSA-44).
  • MCP on Windows: normal C:\ paths are accepted; network and device paths are refused.
  • Desktop app, Scanner: a folder name that starts with a dash is passed on as a folder name, never read as an option.
Changed
  • Encrypting to a recipient key without a password no longer runs Argon2id on an empty password, about 210 ms faster per file.
  • Usage receipts are sent in batches instead of one request per command; logging out sends the pending ones.

v7.2.43 Cryptography bill of materials (CycloneDX); the scan is free in every app

September 28, 2026

Added
  • qnsqy scan <folder> --format cyclonedx writes a CycloneDX 1.6 cryptography bill of materials (CBOM) of the keys, certificates, encrypted files and signatures it finds in files. It states only what the scanner read, and marks an algorithm assumed from a file type as assumed. It covers files only, not cryptography inside source code, programs, container images or network traffic. Checked with the CycloneDX project's validator and the 1.6 JSON schema (a structural check, not a certification). Also in the MCP scan tool, the desktop app and the terminal app.
Changed
  • The read-only scan is free on every plan in every app: the desktop app's Scanner page now opens on Free and Pro, and the terminal app lists Scan on every plan. An account is still needed. Migration stays on Business.
  • The scan's help no longer calls its reports "for HIPAA/healthcare compliance": they are useful input for an internal audit, and QNSQY itself is not HIPAA-audited.
  • scan --my-files writes text, JSON or CSV only; other formats stop with an error.
Fixed
  • Scanner: ML-DSA, SLH-DSA and ML-KEM keys in the standard key formats that OpenSSL 3.5 writes were reported as RSA-2048. They are now named from their NIST identifiers.
  • Scanner: X.509 certificates are read for the key they carry and for the algorithm their issuer signed them with, so a certificate with a post-quantum key signed with RSA or ECDSA is not reported as post-quantum safe.
  • Scanner: a file read only in part is also listed as "Unknown (file partly read)", so it is never reported as safe on the part that was read. Certificates signed with SLH-DSA (over 64 KiB) are no longer skipped.
  • Scanner: QNSQY's own FN-DSA, HQC and LMS keys were reported as ML-KEM-768; they are now named correctly. Each algorithm and each recommendation is listed once per file.
  • Scanner: the Critical risk text said "broken by quantum computers". No quantum computer able to break RSA or ECDSA is known to exist yet, so it now says "vulnerable to a future quantum computer".
  • MCP: a tool whose command printed more than 64 KiB (for example a scan of a few dozen files) hung until its 300-second timeout. Its output is now read while the command runs.

v7.2.42 SHA-512 hash profile, integrity-check fix, desktop and terminal app fixes

September 26, 2026

Added
  • A SHA-512 hash profile you can choose per file: qnsqy encrypt --hash-profile sha512, or "Hash profile" on the desktop app's Encrypt page and in the terminal app's encrypt forms. Choose it when a policy asks for SHA-2 hashing; otherwise keep the default, which is unchanged. With it, the file's key derivation, header check, integrity hash and signature digest use SHA-512 (HKDF-SHA-512, HMAC-SHA-512). Password hashing (Argon2id) and the key combiner of X25519 hybrid keys stay as they are, so a file with no BLAKE3 step needs a pure ML-KEM recipient key, no password, no escrow and no LMS signature. Batch encryption and remote backup keep the default profile. Decrypt, verify and the integrity check detect the profile from the file. Files in this profile need QNSQY 7.2.42 or later to open; older versions refuse them rather than misread them.
Fixed
  • verify-integrity reported "INTEGRITY FAILED" on every signed, escrowed or provenance-signed file. It now checks exactly the encrypted data its stored hash covers, and still fails on any change to that data. As before, it does not check the encrypted header or any signature; decrypt and verify do.
  • Desktop app, Secure Delete: "Delete Permanently" now asks before anything is destroyed, naming the file, the number of overwrite passes and any storage warning. Answering "No" deletes nothing.
  • Desktop app: the Audit page lists the log entries after "Load" (before, only the count appeared); a long Verify Integrity result wraps; the sidebar's last lines are no longer hidden under the status bar.
  • The scanner reports the real size of RSA keys (for example RSA-3072 or RSA-4096) instead of labelling every RSA key RSA-2048, and names elliptic-curve, Ed25519, X25519 and DSA keys by their type. A key file it cannot parse (for example an encrypted one) keeps the label from its header line.
  • On a new installation, two QNSQY commands started at the same moment could each create their own machine identity, so a saved sign-in or audit data written by one could later fail to open. Creating it is now locked (on file systems that support locks), so every process uses the one identity on disk; an existing identity is never changed.
  • Two QNSQY commands opening the audit trail at the same moment on a new installation could fail, or leave a trail that failed its own check (Business). Both now share the trail and its signing key.
  • The QNSQY library (qnsqy-core) now refuses secure deletion of a folder on Windows with the same "not a file" error as the program, instead of a generic input/output error.
  • A declined shred now ends with an error, "Aborted: nothing was deleted", instead of reporting success.
  • Linux: the sandbox banner no longer says "partially enforced, upgrade to 5.13+" on current kernels; the protection itself did not change.
  • Terminal app: operations work when the program file is renamed or started through a link; required fields are checked before a command runs; a form that would wait for a passphrase (a new key without "No passphrase", or a passphrase-protected key) is refused with the reason instead of freezing the app; at 80 columns every menu entry is shown whole and long descriptions wrap; the duplicate Secure Delete entry is gone; results say when a file was signed and show each error once; audit and migrate results read clearly; wrapped lines keep their margin.

v7.2.41 Fixes from an internal security audit; desktop and terminal app fixes

September 25, 2026

Security
  • decrypt --verify-key checks the signature before it writes any plaintext. Before, it checked after the decrypted file was written and then deleted it on failure, so a crash at the wrong moment could leave the plaintext of an unsigned or tampered file on disk.
  • Wrong passphrases are rate-limited on every path that unlocks a private key, including signing, encrypting with a signing key, threshold decryption and batch jobs with a key.
  • Linux sandbox: the temporary folders (/tmp, /var/tmp and the user's runtime folder) can be written to but not run from.
  • Threshold decryption wipes its private keys from memory after use.
  • Temporary files are created readable by the owner only, without following links; system tools are started by their full path; MCP output paths are checked; the desktop app checks imported keys and refuses links.
Fixed
  • Batch encryption now adds the organization's escrow block, as single-file encryption does. Before, batch output had none.
  • devices list --json works; the desktop app's Settings page uses it.
  • Terminal app: escrow key generation asks for its password; before, it waited for ever.
  • Desktop app: encrypt-and-sign with a passphrase-protected signing key asks for the passphrase.
  • Desktop app on Linux: the password prompt works when it opens in the XFCE or MATE terminal.
  • After a plan upgrade, the apps check the plan online at start when the saved plan is Free, so a stale Free plan no longer sticks.
  • The .deb package lists the X11 libraries the desktop app needs.
  • Desktop app: the "Equivalent command line" is right for encoding decode, key signing, keyfile generation and escrow.
Changed
  • The desktop and terminal apps offer the SHA-224, SHA-512/224, SHA3-224 and SHAKE128 hashes and the base32, base58, base64-url and upper-case hex encodings.
  • SHA-224, SHA-512/224 and SHA3-224 are marked legacy: NIST's draft SP 800-131A Rev. 3 proposes retiring them after 2030. hash and hash-verify print a notice when one is used; the digest is unchanged.
  • FN-DSA is described as pre-standard, because NIST has not published FIPS 206 yet. HQC is described as pre-standard too.
  • keygen-sign and keygen-enc warn clearly when --no-passphrase is used.
  • The scanner's advice for RSA, ECC and DH keys cites the dates in NIST IR 8547 (draft).
  • ML-DSA now uses a newer release of its open-source library. Signatures are byte-for-byte the same, and existing keys still load.

v7.2.40 GUI/TUI verdict, flag, and hardening-status fixes

August 31, 2026

Fixed
  • The sign / verify result (Signature VALID, algorithm, public-key hash) now prints to standard output, so the desktop app shows the real verdict instead of a bare "Completed".
  • The terminal UI time-lock now sends the --duration option the binary expects, fixing a rejected command.
  • The ASLR / NX hardening status now reports "unknown" instead of a false "failure" when the in-process sandbox legitimately blocks the reads used to check it; the protections themselves stay on.
  • Two desktop password flows were repaired: deniable encryption now accepts the real and decoy passphrases correctly, and organization escrow key generation no longer fails to launch from the graphical app.
Added
  • A per-algorithm video demo gallery at /demos and a full graphical, terminal, and command-line user guide at /docs.
Changed
  • Tier-capability documentation corrections (Free / Pro / Business).

v7.2.39 Falcon constant-time signing and release-pipeline hardening

August 16, 2026

Security
  • FN-DSA (Falcon) signing was made constant-time, removing a key-dependent timing side channel in signature generation.
Added
  • Account provenance signing (qnsqy provenance): a file can carry an ML-DSA signature from the account that made it, to show which account produced it and to detect later changes. Signing is on Business; checking works offline on every plan and accepts only keys you trust. This work was prepared as 7.2.38, which was not published on its own.
Fixed
  • The release and website deploy pipeline was hardened with a symlink-safe, fail-closed upload guard, so a release can no longer publish an unintended file.
  • Scanner: OpenSSH private keys are reported with their real key type (RSA, ECDSA, Ed25519 or DSA). Before, every OpenSSH-format RSA key was labelled Ed25519.
  • When scan -o will not overwrite an existing report, it now says so with a clear error that names --force, and exits with an error code.
Changed
  • Verified across a 24-distribution operating-system matrix (glibc 2.35 floor) with byte-identical output on every supported distribution.

v7.2.37 Performance and audit-chain integrity

July 11, 2026

Fixed
  • Removed per-operation network round-trips to the billing service, cutting typical encrypt latency from about 1.7 seconds to about 0.28 seconds.
  • Fixed an audit-chain fork that could occur under concurrent writers, so the tamper-evident log stays a single consistent chain under load.
Changed
  • Full open-source attribution: third-party license notices covering the complete dependency tree now ship in every package.

v7.2.36 Packaging, dependency, and legal-attribution hardening

July 6, 2026

Added
  • Every Linux .deb and .rpm package and the npm wrapper now ship a THIRD-PARTY-NOTICES.txt file carrying the full open-source license text for all 545 upstream crates QNSQY depends on, so the required attribution travels with the software you install.
Packaging
  • The packages now declare the glibc 2.35 floor as a formal dependency, so a package manager on an older system refuses the install up front instead of letting it fail at first run.
  • GTK 3 is now a weak (optional) dependency rather than a hard requirement, so lean and headless server installs no longer pull in a full desktop graphics stack just to use the command-line tool.
  • The .rpm packages are now GPG-signed, matching the signing already in place for the apt repository.
Fixed
  • The installer now runs a glibc precheck before installing, prints an accurate message naming the required glibc 2.35 when the system is too old, and exits with a non-zero status when it refuses to proceed, so scripted and CI installs can detect the refusal instead of continuing blindly.
Changed
  • The program binary and its cryptography are unchanged from 7.2.35. This release is packaging, dependency-metadata, and legal-attribution hardening only.

v7.2.35 Full-suite verification and closed open items

July 3, 2026

Added
  • A pinned set of 183 official post-quantum test vectors now runs as a hard gate on every build. The official conformance batteries (NIST ACVP, known-answer tests, Wycheproof, and CNSA) all pass with zero failures.
Security
  • Hardened file handling end to end: opening a file is now safe against a last-moment swap (time-of-check to time-of-use), secret material is handled more strictly, and the automation (MCP) interface enforces owner-only permissions on Windows.
Fixed
  • Aligned the desktop app, terminal interface, and automation interface so every feature behaves identically no matter how you use QNSQY, and the install script now handles root and sudo correctly.
Changed
  • More honest labeling of the attribute-based encryption modes, plus general build and packaging cleanup.

v7.2.34 Attribute-based encryption, steganography, and deniable encryption across every interface

July 3, 2026

Added
  • The real attribute-based encryption (ABE) authority workflow, steganography capacity checks, and device management are now available in the desktop app, the terminal interface, and the automation (MCP) interface, not just the command line.
Fixed
  • Corrected a billing edge case that could overcharge for certain algorithm short names (for example ml-kem768 and ml-dsa65).
Security
  • Mirrored a batch of hardening fixes across both internal cryptography engines so they stay byte-for-byte identical, including an added guard around HQC key handling and audit-chain integrity improvements for HIPAA-style logging.
Changed
  • Documentation now describes the two-phase network model and the post-quantum test coverage accurately.

v7.2.33 Decrypt backoff fix, privacy and labeling refinements

June 28, 2026

Fixed
  • After several wrong password attempts, decrypt now applies a short, bounded backoff instead of a long lockout. A correct password is never held back for long: earlier builds could keep the right password locked out for up to about an hour after a few failed tries.
Privacy
  • Strengthened the website's privacy posture: the data controller is now named explicitly, the GDPR lawful basis for processing is stated, and error-monitoring scripts load only after you accept cookies.
Changed
  • More precise algorithm labeling: HQC is now described as a NIST-selected algorithm, and FN-DSA is described as a FIPS 206 draft.
  • Minor copy and credits updates.

v7.2.32 npm runtime glibc guard + repository and artifact refresh

June 23, 2026

Added
  • The npm wrapper now performs a runtime glibc check in the launcher: on a system with glibc older than 2.35 it stops with a clear requires glibc >= 2.35 message instead of failing with a confusing linker error. Validated to block on Debian 11 and AlmaLinux 9, and to run on Debian 12, AlmaLinux 10, and Fedora 44.
Packaging
  • The apt and dnf repositories were regenerated and re-signed, and the published dnf repo file (qnsqy.repo) and apt Release now point at 7.2.32. The Sigstore cosign signature was refreshed, so all three signature layers (GPG repository metadata, post-quantum ML-DSA-87, and cosign / Sigstore) are current over the 7.2.32 release.
  • All download artifacts were version-bumped to 7.2.32 across npm, the download page, the CDN (.deb, .rpm, and both Windows .exe builds), and the apt and dnf repositories.
Fixed
  • The release tooling now retries the publishing-account preflight check on slow or flaky network links.

v7.2.31 Restored glibc 2.35 portability

June 23, 2026

Fixed
  • Restored portability across the supported Linux distributions. The Linux artifacts are now built in a glibc 2.35 (Ubuntu 22.04) environment, so apt and dnf installs work on Ubuntu 22.04+, Debian 12+, Fedora 40 to 44, and AlmaLinux 10, and the binary correctly refuses to run on distributions with glibc older than 2.35.

v7.2.30 Offline-receipt DoS fix + auto-renewing subscription cache

June 23, 2026

Security
  • Fixed a self-inflicted denial of service. After more than 100 billing receipts accumulated during extended offline use, the next operation could be killed by the seccomp sandbox while attempting a post-sandbox network sync, including the always-free hash, keygen, and encrypt operations. Receipt sync now runs only before the sandbox is applied, so offline operations never crash and any queued receipts flush on the next online operation.
Added
  • The subscription cache now auto-refreshes in the background across every interface (CLI, TUI, MCP, and GUI) whenever the machine is online, so paid users no longer need to run qnsqy activate by hand to renew their offline grace window. Offline behavior is unchanged: the refresh is bounded and skipped quickly when there is no connectivity.
Fixed
  • verify-release --pubkey now accepts a bare path to a key file, not only the @file form.
  • verify-integrity success output now states clearly that it authenticates the encrypted header (a fast integrity check); full whole-file authentication is performed by decrypt via AEAD.
  • GUI success banner now lays out correctly.

v7.2.28 Proprietary license + path-redaction & CORS fixes

June 18, 2026

Fixed
  • Remote-backup path redaction no longer mangles non-path tokens such as I/O in logs and audit output.
  • Free-download endpoint CORS no longer emits a literal undefined Access-Control-Allow-Origin header when the origin is not allowed.
Licensing
  • The Linux .deb package now carries the proprietary QNSQY end-user license. The apt/dnf repository was regenerated and re-signed across all three layers (GPG, ML-DSA-87, and Sigstore cosign). The program binary is unchanged.

v7.2.27 Licensed-binary integrity fix

June 18, 2026

Fixed
  • The per-customer license trailer appended to licensed binaries is now excluded from the binary's self-integrity hash, so the startup integrity self-check passes on licensed builds.

v7.2.26 Audit-chain & scan hardening

June 16, 2026

Security
  • Audit-chain drain fix (H1) and a cross-organization access guard (M3).
  • Scan no longer overwrites an existing output without confirmation (L1).

v7.2.25 Remote Backup

June 13, 2026

Added
  • Dedicated Remote Backup page and full encrypt/decrypt/batch wiring for zero-knowledge push/pull/sync to S3-compatible storage (available on every tier).

v7.2.24 Signed repos + Sigstore

June 12, 2026

Added
  • GPG-signed Linux apt/dnf repositories and a Sigstore (cosign) keyless signature layer over the release checksums.
  • An npm publish preflight gate that blocks releasing a wrapper whose integrity hashes do not match the live platform binaries.
Fixed
  • Token-handling fix (HIGH-1) and a pass to make site claims strictly truthful.

v7.2.21 to v7.2.23 npm package updates only

June 5 to 9, 2026

Changed
  • Versions 7.2.21, 7.2.22 and 7.2.23 were published on npm only, while the npm package moved to separate Linux and Windows packages. All three install the 7.2.20 program; the next program release was 7.2.24. npm 7.2.29 (June 18) was also a package-only update and installs the 7.2.28 program. npm marks these versions as superseded.

v7.2.20 Portable glibc 2.35 rebuild

June 1, 2026

Build
  • The Linux binary is now built against an Ubuntu 22.04 (glibc 2.35) baseline, so a single artifact runs on Ubuntu 22.04+, Debian 12+, Fedora 40+, and AlmaLinux 10 instead of only the build host's distribution. Binary 51,163,752 bytes; BLAKE3 integrity hash 38ee87af…472b25be patched in; startup self-check passes.
Fixed
  • GUI: take the child-process lock before kill/wait in the backend shutdown path, closing a data race when the desktop app shuts down.
Verification
  • Re-verified on the 7.2.20 build with zero failures: 461 library unit tests, 390 KAT and structural vectors, 14 crypto edge-case tests, 12 multi-recipient roundtrip tests, 16 v6.1 format tests, and the Project Wycheproof adversarial AEAD, KDF/MAC, KEM, and signature suites. cargo audit and cargo deny clean. This is byte-for-byte test-vector replay and internal review, not FIPS 140-3 / CMVP certification.

v7.2.19 Project Wycheproof adversarial vectors + security remediation

May 28, 2026

Added
  • 15 official Project Wycheproof v1 vector files (fetched verbatim from the public C2SP/wycheproof repository) plus four test harnesses. Roughly 2,937 vectors execute on every build with 0 failures. They test the reject paths (tampered AEAD tags, malleable signatures, malformed keys, twisted-curve points), complementing the valid-input ACVP sweep. Each harness fails the build if any valid vector is rejected, any invalid vector is accepted, or zero vectors run.
  • AES-256-GCM and XChaCha20-Poly1305 vectors test QNSQY's own AEAD code; Ed25519, X25519, ML-DSA-44/65/87, ML-KEM-512/768/1024, HKDF-SHA256/512, HMAC-SHA256/512, and IETF ChaCha20-Poly1305 vectors test the exact RustCrypto and dalek crate versions QNSQY ships.
Security
  • An internal from-scratch audit (2026-05-28): 118 findings (1 critical, 4 high, 35 medium, 49 low, 29 informational), remediated and verified. No confirmed cryptographic break. Post-fix verification: siepmu 38 tests, billing API 203 tests, and the cross-code-base, cryptography and file-format regression suites all pass with 0 failures and 0 cryptographic regressions.
  • Production v7.2.19 release build (fat link-time optimization), binary self-verifies its BLAKE3 integrity hash at startup.
Verification
  • This is not FIPS 140-3 / CMVP certification. It is byte-for-byte test-vector replay plus internal review against the production crates. CMVP is on the roadmap; no application has been submitted.

v7.2.18 NIST ACVP validation harness

May 13, 2026

Added
  • A new test suite that replays the full ACVP-Server v1.1.0.42 vector set (commit 15c0f3deeefbfa) against the same Rust crates QNSQY ships. Sweep wall-clock 518.09 s (2026-05-15) on a Fedora 43 workstation.
  • 18,703 vectors passed, 0 failures, 11,259 skipped (unimplemented parameter sets, e.g. RSA, ECDSA, AES-CBC), 29,962 total vectors in the NIST ACVP-Server v1.1.0.42 reference tree. 33 of 50 ACVP algorithm directories at 100% NIST coverage.
  • Coverage spans all 22 HMAC directories, ML-DSA keyGen + sigVer (full coverage) and ML-DSA sigGen externalMu deterministic, ML-KEM keyGen + encapDecap, SLH-DSA across every parameter set (pure, preHash, deterministic, randomized, external, internal interface), SHA-2-256 / 512 / 512-256 -1.0 (AFT + MCT-alternate + LDT to 8 GiB), SHAKE-128-FIPS202, XECDH-SSC RFC 7748 self-consistency, AES-GCM tagLen-128 cases, EdDSA pure Ed25519 sigVer.
Verification
  • This is not FIPS 140-3 / CMVP certification, and not an external audit. It is reproducible byte-for-byte ACVP test-vector replay against the production crates. CMVP is on the roadmap.
  • Reproduce with the standalone, self-contained harness published on /validation (source access for customers and auditors on request under NDA).
  • Documented skips fall into two buckets: NIST vectors outside QNSQY scope (RSA, ECDSA, AES-CBC/CTR/CCM, KMAC, CMAC, KDF-TLS / SSH / IKE, DRBG, KAS-ECC), and upstream Rust crate API limits (ML-DSA externalMu randomized requires private raw_sign_mu, ML-KEM encapsulationKeyCheck / decapsulationKeyCheck not exposed by ml-kem 0.2.3, bit-oriented SHA/SHAKE inputs, SHAKE variable-output MCT state machine, SP 800-56C TwoStep encoding).
Build
  • Production code unchanged; the dependencies the test suite added are test-only and not in the release program.
  • Full per-vector log and report published on the Validation page.

v6.1 file-format minor revision

May 8, 2026

Privacy
  • Tier byte (offset 8) and the six private feature-flag bits (HSM-wrapped, escrow, directory archive, integrity, keyfile-derived, ABE) move out of the plaintext fixed header into a 4-byte EncryptedHeaderMeta prefix inside the AEAD-encrypted header. A passive observer no longer learns the tier or these bits from the fixed header alone.
  • Three flag bits remain plaintext because the parser needs them before decryption: FLAG_RECIPIENT_MODE, FLAG_HYBRID_MODE, FLAG_MULTI_RECIPIENT.
  • The verify-integrity command and the corresponding MCP tool now rely on a structural indicator at reserved[24] == 0x01 instead of the moved FLAG_INTEGRITY bit, so corruption can still be checked without the decryption key.
  • Two intentional residual fingerprints remain by design and are documented in the spec: the reserved[24] integrity-presence indicator, and the plaintext QSEC magic of the optional escrow trailer at end-of-file.
Features
  • New qnsqy scan --my-files command inventories the user's own QNSQY-family files in a directory tree, identifies each by magic bytes (QNS6, QSDN, QSPG, QSP3, QSP4, QSST, QSS2, QSTL, QSYM, QSKF, qsthresh, QSVT, QSIG, QSEC), and (with --key or --password-stdin) decrypts .qs headers far enough to report the sealed tier and feature flags. Output formats: human table (default), JSON (--json), CSV (--csv) for compliance evidence packs.
  • IANA media-type registration application drafted for application/vnd.quantumsequrity.qnsqy per RFC 6838 §5.6 vendor tree. PRONOM signature definition and libmagic magic(5) entry also drafted. Submissions to IANA / PRONOM / libmagic-upstream are pending human steps tracked in the reference-implementation repository.
Fixed
  • The integrity-hash check now reads the right header byte in v6.1 files; without this, every v6.1 file with an integrity hash would have been silently reported as having no integrity data.
  • GUI file-info panel shows (sealed) for the tier on v6.1 files instead of misreporting them all as Free.
  • Decrypt CLI directory-archive routing now peeks for the tar magic at offset 257 of the decrypted output, so v6.1 directory-encrypted files (where FLAG_DIRECTORY is sealed) unpack back into a directory tree as expected.
  • Escrow-decrypt no longer fails-fast on the plaintext flag bit for v6.1 files; the QSEC magic appended after the chunked body is the authoritative signal.
  • The plan check before decryption is skipped for v6.1 files in both code bases, avoiding a wasted Argon2 derivation before the check after decryption.
Compatibility
  • v6.0 files continue to decrypt unchanged; the reader auto-detects the on-disk minor version and follows the legacy plaintext layout for pre-existing files.
  • Header MAC scope and AEAD construction unchanged; the moved tier and flag bits are authenticated by the same MAC and AEAD tag that already protect the encrypted header.

Security hardening update

April 5, 2026

Security
  • Remediated 1 HIGH, 10 MEDIUM, 1 LOW, and 4 INFO findings across 30 files
  • Continued hardening of billing API session handling and authentication flows
Fixed
  • HKDF key-commitment binding improvements in both code bases
  • Session authentication middleware hardening in billing API
  • SSO OIDC and SAML handler security fixes

Security hardening update

April 5, 2026

Security
  • Remediated 3 HIGH, 9 MEDIUM, 5 LOW findings across 18 files
  • An internal review of the Rust cryptographic core (not an external audit) found no further issues
  • 21 of 26 findings confirmed true positives (2 partial, 5 false positives removed)

Security hardening update

March 31, 2026

Security
  • 8-agent full directory audit: 0 CRITICAL, 8 HIGH, 27 MEDIUM, 20 LOW, 15 INFO
  • All prior audit fixes verified intact
  • Six fixes so that symbolic links are not followed where they must not be
Changed
  • Pricing restructured to 3-tier model: Free, Pro ($29/mo), Business ($149/mo)

Security hardening updates

March 14-15, 2026

Security
  • An internal audit by six automated reviewers across 200+ source files: 0 critical, 5 high, 11 medium, 11 low findings
  • A follow-up audit confirmed those fixes and found 3 more high and 2 medium findings
  • Replaced unsalted SHA-256 password hashing with PBKDF2 (600k iterations, 16-byte salt)
  • Fixed subscription upgrade bypass allowing $0 Business tier access
  • Fixed deleted users re-authenticating via magic links
  • AuditChain signing key and encryption key now Zeroizing for proper memory cleanup
  • PBKDF2 timing oracle patched with constant-time dummy hash
  • The two code bases now agree on ML-KEM-768 for the Pro plan
Added
  • Website SEO improvements: Organization schema, publisher metadata, sameAs social links
  • FAQ entry addressing "Quantum Sequrity" brand name
  • Social media assets: profile pictures and banner images (Syne Bold + Outfit branding)
Changed
  • Cleaned up stale copies and junk files to _cleanup-backup directory
Fixed
  • Webhook handler: full refund now cancels subscription and downgrades to free
  • Server-side tier check updated with ml-dsa-65-ed25519 and ml-dsa-87-ed25519
  • Shred device name validation: reject path traversal characters
  • qs-chat storage: files are created exclusively, which blocks a hard-link race
  • Shamir secret sharing: constant-time field division in both code bases
  • Email templates: escapeHtml() applied to plan names and invoice data

Security hardening update

March 9, 2026

Security
  • 5-agent deep audit: 40+ fixes across 3 rounds
  • MCP server: now runs inside the sandbox
  • MCP signup/login routed through CLI subprocess for isolation
  • Subscription cache bound to a hash of the account key; fails closed when it is missing
  • Fixed undefined behaviour when wiping the HQC shared secret
Added
  • File header: flag bits, an Argon2 version field, reserved bytes and a minimum-length check
  • Encryption checks the algorithm limits of your plan
  • The offline grace period is its own plan state
  • MCP tier refresh every 1 hour, signup TLS 1.3, rate limiter bounded
Fixed
  • Passwords read from standard input are wiped after use
  • The padding size calculation can no longer overflow
  • Ed25519 keys are wiped reliably
  • Internal request objects no longer print or copy secrets
  • Anti-debugging check: fewer false alarms

Earlier Releases

January - March 2026

Added
  • 370 KAT tests across 17 modules with official NIST ACVP vectors
  • QSPG v2 and QSDN v2 file formats for PQC hybrid polyglot and deniable encryption
  • Seccomp sandboxing for all threads with glibc NSS path allowance
  • Abort signals raised inside the C cryptography libraries are handled
  • Panics inside the HQC, Falcon and LMS libraries are caught and reported as errors
  • MCP server with 48 of 56 CLI commands exposed via GUI
  • qs-chat: voice/video roadmap targeting high-assurance environments with ML-KEM-1024 + AES-256-GCM
  • Ctrl+C terminal state restoration during password prompts
  • Admin panel: emergency lockdown, password reset, searchable geo dropdown
  • 6 MCP tools and 4 GUI backend methods for feature parity
Changed
  • 3-tier billing model: Free, Pro, Business (merged Enterprise and Ultra into Business)
  • Tier determined at runtime via billing server only. No compile-time overrides
  • Machine key: BLAKE3 qnsqy-machine-key-v5 (removed cpu MHz and hostname)
  • Release builds keep panic unwinding, so a library panic cannot be used to stop the program
Security
  • Clock handling fails closed, with protection against setting the clock back
  • The file size is checked again after authorization, closing a time-of-check gap
  • MCP passwords are held in memory that is wiped after use
  • Private keys never returned via MCP wire protocol

Questions?

Check out the documentation or reach out for help.

Documentation FAQ