v7.0 Scope
QNSQY v7.0 expands the tool from single-file password-based encryption (v6 and earlier) to multi-party and organizational features: threshold encryption, Shamir secret sharing, audit logging, recipient groups, encryption policy, key escrow, and SIEM export. The core crypto (ML-KEM + X25519, ML-DSA + Ed25519, AES-256-GCM, Argon2id) is unchanged.
This post walks through each major v7.0 feature, who it is for, and concrete scenarios where it applies.
New Enterprise Features
Threshold Encryption: No Single Person Holds the Key
Threshold encryption solves a problem that every organization eventually faces: what happens if the one person who knows the password gets hit by a bus, goes rogue, or simply forgets it?
With threshold encryption, QNSQY splits the decryption key into multiple pieces using a technique called Shamir's Secret Sharing (invented by cryptographer Adi Shamir in 1979). You choose how many total pieces to create and how many are needed to reconstruct the key. For example, in a "3-of-5" setup, the key is split into 5 pieces and any 3 of them can unlock the file. Any 2 pieces (or fewer) reveal absolutely nothing about the key. This is not simply dividing the key into parts; it is mathematically guaranteed that fewer than the threshold number of shares provides zero information.
Real-world scenario: Board of Directors. A company's board votes to encrypt the emergency succession plan with 3-of-5 threshold encryption. Each of the five board members receives one share. If the CEO is incapacitated and three board members come together, they can decrypt the document. No single board member (including the CEO) can access it alone. If one member leaves the company, the remaining four can still access the file. If two members leave, the document becomes inaccessible until new shares are generated.
Real-world scenario: Regulatory compliance. A hospital encrypts patient database backups with 2-of-3 threshold encryption. The CTO, the Chief Medical Officer, and the IT Director each hold one share. Any two can authorize a restore. This satisfies dual-control requirements in HIPAA security audits while ensuring that a single compromised credential cannot expose patient data.
Threshold encryption is available on the Business tier. The command is straightforward:
qnsqy threshold-encrypt -i sensitive.pdf -m 3 -n 5 -r alice bob carol dave eveSteganography: Hidden Encryption
Standard encryption makes it obvious that something is being hidden. An attacker who sees a .qs file knows it is an encrypted file, even if they cannot read its contents. In some situations, the mere existence of an encrypted file draws unwanted attention.
Steganography solves this by hiding encrypted data inside innocent-looking files. QNSQY v7.0 can embed encrypted payloads inside images. The result looks like a normal photograph. You can open it in any image viewer and see a perfectly normal picture. Only someone who knows the password and uses QNSQY's extract command can recover the hidden data.
Real-world scenario: Journalism. A journalist working in a country with authoritarian surveillance needs to transport encrypted notes. A folder full of .qs files on their laptop would invite confiscation. A folder of vacation photos that happens to contain hidden encrypted documents is far less suspicious.
Real-world scenario: Corporate whistleblowing. An employee needs to securely move evidence of financial fraud to a lawyer. Emailing encrypted attachments through the corporate mail system would trigger DLP (Data Loss Prevention) alerts. A photo attachment does not.
qnsqy stego hide -i secret.pdf --carrier vacation.png -o vacation_modified.png
qnsqy stego extract -i vacation_modified.png -o recovered.pdfTimelock Encryption: A Digital Time Capsule
Timelock encryption locks a file so that it cannot be opened until a specific amount of computation has been performed. Think of it as a puzzle that a computer must solve sequentially; there is no shortcut, no way to parallelize it, no way to speed it up by throwing more computers at it. The puzzle is calibrated so that it takes a predictable amount of wall-clock time to solve.
Real-world scenario: Sealed-bid auctions. A procurement office collects encrypted bids from vendors. Each bid is timelock-encrypted to unlock at the same moment: the bid opening deadline. No one, not even the procurement office, can peek at the bids early. This eliminates bid-rigging and ensures fairness.
Real-world scenario: Estate planning. A parent writes letters to their children, encrypted with a timelock set for 20 years. The letters can only be opened after the configured period, ensuring the messages are delivered at the intended time regardless of what happens to the parent.
qnsqy timelock encrypt -i letter.pdf --duration 8h
qnsqy timelock calibrate # Measures your CPU to estimate solve timesEncryption Policy Management
Organizations need consistent encryption practices. If one department encrypts with ML-KEM-1024 and another uses ML-KEM-512, if one team uses 30-character passphrases and another uses 8-character passwords, the weakest link determines the organization's actual security posture.
QNSQY v7.0 introduces policy files that define encryption rules for an organization. A policy can require a minimum algorithm strength, a minimum password length, mandatory signatures, or specific AEAD ciphers. When a policy is active, QNSQY enforces it automatically and refuses to encrypt files that do not meet the requirements.
Real-world scenario: A defense contractor sets a policy requiring ML-KEM-768 minimum, Argon2id with 256 MB memory, and mandatory ML-DSA signatures on all encrypted files. Every employee's QNSQY installation enforces this policy. A new hire cannot accidentally encrypt a classified document with weak settings.
qnsqy policy init
qnsqy policy set min-kem ml-kem-768
qnsqy policy set require-signature true
qnsqy policy showEscrow Recovery: The Safety Net
What happens when an employee leaves the company and their encrypted files need to be accessed? What about when someone forgets their password with no backup? Escrow recovery provides an organizational safety net without weakening individual file security.
An organization generates an escrow key pair. When files are encrypted with escrow enabled, a copy of the file's encryption key is also encrypted with the organization's escrow public key and stored in the file header. If the original password is lost, the escrow private key (held by authorized administrators) can recover the file.
Real-world scenario: Employee offboarding. An engineer who encrypted dozens of project files with their personal password leaves the company. Without escrow, those files are permanently lost. With escrow, the IT security team uses the escrow key to recover the files and re-encrypt them under a new owner.
qnsqy escrow-keygen --org "Acme Corp"
qnsqy escrow-decrypt -i locked-file.qs --escrow-key acme-escrow.keySIEM Integration and Audit Logging
Every encryption, decryption, signature verification, key generation, and file deletion operation in QNSQY v7.0 is logged. These logs are stored in a tamper-evident hash chain: each entry includes a cryptographic hash of the previous entry, so modifying or deleting any log entry breaks the chain and is immediately detectable.
For organizations that run centralized security monitoring (SIEM systems like Splunk, Elastic, or Microsoft Sentinel), QNSQY can export these logs in CEF (Common Event Format), JSON, or Syslog format. This means your encryption operations appear in the same dashboards and alerting systems as your firewall logs, authentication events, and intrusion detection alerts.
Real-world scenario: HIPAA compliance. A hospital's security team needs to demonstrate that patient records are encrypted at rest and that every access is logged. QNSQY's audit logs feed directly into their Splunk instance, providing auditors with a searchable, tamper-evident record of every operation.
Expanded Algorithm Support
12 Key Encapsulation Algorithms
QNSQY v7.0 supports 12 KEM (Key Encapsulation Mechanism) configurations. Think of a KEM as the system for securely exchanging the key that actually encrypts your file. The file itself is always encrypted with AES-256-GCM or XChaCha20-Poly1305 (symmetric ciphers). The KEM protects the symmetric key during the exchange.
- ML-KEM-512 (hybrid with X25519): Available on Free tier. NIST FIPS 203, Security Level 1. Good for most personal use.
- ML-KEM-768 (hybrid with X25519): Available on Pro tier. Security Level 3. Recommended for sensitive business data.
- ML-KEM-1024 (hybrid with X25519): Available on Pro tier. Security Level 5. Maximum lattice-based security.
- HQC-128/192/256 (hybrid with X25519): Available on Business tier. Code-based KEM, provides algorithm diversity. If a weakness is ever found in lattice math (which ML-KEM relies on), HQC uses completely different math (error-correcting codes) and would not be affected.
- Pure PQC variants: All six algorithms above are also available without the X25519 hybrid layer, for environments that want to go fully post-quantum with no classical component.
8 Hash Algorithms
Hashing is how you verify that a file has not been tampered with. You compute a fixed-size fingerprint (the hash) from the file's contents; if even one bit changes, the hash is completely different. QNSQY v7.0 expanded from 2 to 8 hash options:
- BLAKE3 (default): The fastest cryptographic hash available. Processes data at memory bandwidth speed on modern CPUs.
- SHA-256 and SHA-512: The NIST standards used in TLS, Bitcoin, and most government systems.
- SHA3-256 and SHA3-512: The newer NIST standard based on the Keccak sponge construction, providing algorithm diversity from SHA-2.
- BLAKE2b and BLAKE2s: Widely used in password hashing and file integrity checking.
- SHAKE256: An extendable-output function from the SHA-3 family, producing hash outputs of any length.
Hybrid Digital Signatures (Pro+)
Digital signatures prove who created or approved a file. Like encryption, QNSQY uses a hybrid approach: every signature combines ML-DSA (the NIST post-quantum standard, FIPS 204) with Ed25519 (the classical standard). The signature is valid as long as either algorithm remains secure. This is the same defense-in-depth strategy used for encryption.
Business tier also adds SLH-DSA (FIPS 205, hash-based signatures), FN-DSA (FIPS 206 (draft), lattice-based), and LMS (SP 800-208, stateful hash-based). These additional signature algorithms provide organizations with more options for meeting specific compliance requirements.
Pricing and Tiers
| Tier | Price | Key Features |
|---|---|---|
| Free | $0 | ML-KEM-512 hybrid, ML-DSA-44, AES-256-GCM + XChaCha20-Poly1305, encrypt/decrypt/sign/verify, 100 MB per-file limit for advanced algorithms (ML-KEM-512 + ML-DSA-44 unlimited), GUI + CLI + TUI + MCP |
| Pro | $29/month ($290/year, save 17%) | All ML-KEM levels, all ML-DSA + SLH-DSA, batch operations, vault, audit logs, rekey, 25 GB per-file limit |
| Business | custom pricing (, save 17%) | Everything in Pro + HQC, FN-DSA, LMS, threshold encryption, steganography, timelock, policy, escrow, SIEM export, unlimited file size |
| Enterprise | custom pricing via sales. Air-gap license mode and HSM integration are v7.3 roadmap (not shipping today). |
Decryption, signature verification, hashing, key generation, and secure deletion are free on all tiers. You only pay for encryption and signing operations that use higher-tier algorithms.
Improvements for Everyone
v7.0 is not just about enterprise features. Free users benefit from significant improvements:
- 30% faster encryption through optimized AES-NI usage. On CPUs with hardware AES support (virtually all modern x86 processors), data encryption runs at near-memory-bandwidth speeds.
- Better progress reporting for large files. The CLI and GUI both show real-time throughput and estimated time remaining.
- Reduced memory usage during compression. Files are processed in streaming chunks rather than loaded entirely into memory.
- macOS Sequoia and Windows 11 24H2 full support, including the native GUI on both platforms.
Recipient Groups: Encrypt Once for Many
In a team environment, you often need to encrypt a file so that several specific people can decrypt it. Without groups, you would need to list every recipient each time. QNSQY v7.0 introduces named recipient groups: create a group once, add members by their public keys, and then encrypt to the group name. When the team changes, update the group; you do not need to re-encrypt every file.
Real-world scenario: Legal department. A law firm creates a "litigation-team" group containing all five attorneys and two paralegals working on a case. Every document related to the case is encrypted to the group. When a new attorney joins the case, they are added to the group and can immediately decrypt all future files. Prior files remain accessible only to whoever held group membership at the time of encryption.
qnsqy group create litigation-team
qnsqy group add litigation-team alice.pub bob.pub carol.pub
qnsqy encrypt -i evidence.pdf --group litigation-teamEncrypted Vault: A Password Manager for Files
The vault feature (Pro+) provides an encrypted key-value store protected by a single master password. Think of it as a password manager, but instead of storing website logins, it stores arbitrary secrets: API keys, configuration strings, license keys, private notes, or any text you need to keep safe.
The vault is a single encrypted file. You unlock it with your master password, read or write entries, and lock it again. Each entry is a name-value pair. The vault supports listing entries, adding, removing, editing, and bulk import/export in JSON format.
Real-world scenario: DevOps secrets. A developer team keeps all their production API keys, database credentials, and service tokens in a QNSQY vault. The vault file is stored in the team's private repository. When someone needs a credential, they open the vault, look up the entry, and copy the value. The vault is encrypted with ML-KEM + Argon2id, so even if the repository is compromised, the secrets remain safe.
qnsqy vault init ./team-secrets.qsv
qnsqy vault add ./team-secrets.qsv "prod-db-password"
qnsqy vault get ./team-secrets.qsv "prod-db-password"
qnsqy vault list ./team-secrets.qsvDeniable Encryption: Two Passwords, Two Contents
Deniable encryption (Business tier) creates a file that contains two separate encrypted payloads, each protected by a different password. Enter one password, and you see the decoy content (perhaps some innocuous documents). Enter the other password, and you see the real content. An observer cannot prove that the second payload exists; the file looks identical regardless of which password was used.
Real-world scenario: Traveling with sensitive data. A business executive crossing a border with a laptop may be asked to decrypt files at customs. With deniable encryption, the executive can comply by entering the decoy password, showing harmless travel itineraries. The confidential merger documents remain hidden behind the real password, and there is no technical way for border agents to prove the second payload exists.
Polyglot Files: Hiding in Plain Sight
A polyglot file is a single file that is valid in two formats simultaneously. QNSQY's polyglot feature (Business tier) creates files that look like normal documents (a PDF, a ZIP archive) while also containing an encrypted payload appended after the carrier file's EOF marker. Open the file in a PDF reader, and it displays normally. Process it with QNSQY, and the hidden encrypted data is extracted.
This is conceptually similar to steganography but works with a wider range of carrier formats and does not modify the carrier's visible content at all.
Migrating from Earlier Versions
If you are already using QNSQY v6.x, the upgrade is straightforward. All .qs files created with v6 can be decrypted by v7 without any changes. The file format is backward-compatible. Simply download v7.0 and install it over your existing installation.
There is no need to re-encrypt existing files. They remain secure with their original algorithm choices. If you want to take advantage of new algorithms (like HQC on Business tier), you can re-encrypt specific files at your convenience using the qnsqy rekey command, which changes the encryption without exposing plaintext to disk.
For organizations migrating from GPG, Age, or other encryption tools, QNSQY does not import their file formats directly. The migration workflow is: decrypt with the original tool, re-encrypt with QNSQY, then securely shred the originals. Focus on long-lived sensitive data first, as that is most at risk from "harvest now, decrypt later" attacks.
Security Improvements Under the Hood
Beyond the visible features, v7.0 includes significant internal security improvements:
- Memory protection: All cryptographic secrets (passwords, keys, shared secrets) are stored in locked memory pages (mlock) that cannot be swapped to disk. When the secret is no longer needed, its memory is overwritten with zeros before being released.
- Two-phase network sandbox: On Linux CLI, a two-phase sandbox controls network access. During billing, application-layer controls pin connections to billing.quantumsequrity.com (pinned DNS + TLS 1.3 + PQC envelope). Before any cryptographic operation, seccomp-bpf kills ALL network syscalls at the kernel level (irreversible). Your files, passwords, and keys never leave the machine; even if the application code contained a bug that tried to exfiltrate data, the kernel would block it once the crypto phase begins.
- Binary integrity verification: On startup, QNSQY computes a hash of its own binary and compares it against the expected value. If the binary has been tampered with, execution is halted.
- Constant-time comparisons: All security-sensitive comparisons (password verification, MAC checks, signature verification) use constant-time operations to prevent timing side-channel attacks.
Get QNSQY v7.0
v7.0 is available now for Linux, macOS, and Windows. Free users can download immediately from the download page. Pro and Business subscribers receive the update automatically.
Sources
- NIST FIPS 203: ML-KEM Standard (August 2024)
- NIST FIPS 204: ML-DSA Standard (August 2024)
- NIST FIPS 205: SLH-DSA Standard (August 2024)
- Shamir, A. "How to Share a Secret" (Communications of the ACM, 1979)
- Password Hashing Competition (Argon2 selected 2015)
Related Articles
Originally published at quantumsequrity.com/blog/v7-enterprise-launch.