A
Quantum-Resistant
Built on NIST-approved post-quantum standards (FIPS 203, 204, 205). Not experimental. Production-ready encryption with AES-256-GCM. All tiers include hybrid ML-KEM + X25519 key encapsulation for quantum resistance.
SYSTEM ONLINE
FIPS 203 · FIPS 204 · FIPS 205 · SP 800-208 · HYBRID PQC
QNSQY
-
POST-QUANTUM MIGRATION · NIST FIPS 203 / 204 / 205
Scan & migrate from classical to post‑quantum cryptography
to protect against Harvest Now, Decrypt Later
Attackers copy your encrypted data today to crack it the day a quantum computer breaks RSA and ECC. That is Harvest Now, Decrypt Later. QNSQY scans your data at rest, finds what classical crypto still protects, and re‑encrypts it in place with NIST post‑quantum standards. Your data, passwords, and private keys never leave your machine.
- Algorithms
- 12+
- NIST ACVP
- 19,769 / 0
- Network
- Locked*
- File data sent
- None
ML-KEM-1024·
ML-DSA-87·
FN-DSA-1024·
HQC-256·
SLH-DSA-SHAKE·
LMS/HSS·
X25519·
Ed25519·
AES-256-GCM·
XChaCha20-Poly1305·
Argon2id·
BLAKE3·
ML-KEM-1024·
ML-DSA-87·
FN-DSA-1024·
HQC-256·
SLH-DSA-SHAKE·
LMS/HSS·
X25519·
Ed25519·
AES-256-GCM·
XChaCha20-Poly1305·
Argon2id·
BLAKE3·
Name
QuaNtum SeQuritY
·
Command
·
qnsqy
Extension
.qs
Security At A Glance
Encryption: NIST FIPS 203/204/205 post-quantum algorithms + classical hybrid
Network: File content, passwords, and private keys never leave your machine. Linux CLI: two-phase sandbox -- application-layer controls pin network to billing.quantumsequrity.com during billing (pinned DNS + TLS 1.3 + PQC envelope), then seccomp-bpf kills ALL network syscalls before crypto operations (kernel-enforced, irreversible); Windows and GUI: no kernel-level enforcement, use physical air-gap.
Privacy: No cloud storage of your files. When you are signed in, only the licence check (operation type, data size, algorithm and program version; never file names or contents) goes to our billing server, inside a post-quantum envelope over HTTPS.
01
Why now: the deadlines are set
Data protected today with RSA or elliptic-curve keys can be read later, once a quantum computer can break them, so data copied now is already at risk. Governments have set dates for this. Laws, presidential orders, regulators and mandatory standards require government agencies, the military, national security systems, the NHS and Israeli banks to inventory their cryptography and to plan or carry out the move to post-quantum cryptography. National guidance sets similar dates for other organizations. Each line links to the official text.
| Rule | What it requires | Force |
|---|---|---|
| United States | ||
| Quantum Computing Cybersecurity Preparedness Act (Public Law 117-260, December 2022) | Every federal agency must keep an inventory of its systems that quantum computers could decrypt; OMB must require agencies to prioritize those systems and plan their migration to post-quantum cryptography. | Law |
| National Security Memorandum 10 (May 2022) | Sets the national goal of mitigating as much of the quantum risk as is feasible by 2035. | Presidential directive |
| OMB M-23-02 (November 2022) | Agencies must submit a prioritized inventory of their quantum-vulnerable systems every year until 2035. | Mandatory for federal agencies |
| Executive Order 14412 (June 2026) | Ordered: high-value and high-impact federal systems move to post-quantum key establishment by 31 December 2030 and post-quantum signatures by 31 December 2031. The FAR Council is ordered to propose a rule requiring federal contractors to comply with NIST's standards, including the post-quantum ones, by 31 December 2030. | Presidential order |
| OMB M-26-15 (June 2026) | Agencies had 120 days (to 22 October 2026) to file migration plans. "Data must be protected at rest and in transit"; agencies must prioritize re-encrypting long-lived sensitive data with keys protected by post-quantum mechanisms. | Mandatory for federal agencies |
| NSA CNSA 2.0 and CNSSP 15 | All new national security system acquisitions must be CNSA 2.0 compliant from 1 January 2027, unless otherwise noted; CNSA 2.0 algorithms are mandated for use by 31 December 2031. | Mandated for national security systems |
| Department of War PQC Strategy (April 2026) | All Department of War systems must support post-quantum cryptography by 31 December 2030 and must use it by 31 December 2031. | Binding for Department of War components |
| CISA PQC product categories (January 2026) | For data-at-rest security and full-disk encryption, organizations "should acquire only PQC-capable products". | Federal buying guidance |
| United Kingdom | ||
| NHS Data Security and Protection Toolkit 2026-27 (October 2026) | B3.b, a mandatory policy requirement: NHS organisations must plan to achieve, by the end of 2028, a full discovery exercise and an initial migration plan, and must submit an approved and realistic plan. | Mandatory for NHS organisations |
| NCSC PQC migration timelines (March 2025) | By 2028: full discovery and an initial plan. By 2031: highest-priority migrations done. By 2035: migration complete for all systems, services and products. | National guidance |
| European Union | ||
| Coordinated Implementation Roadmap (EU member states, June 2025) | National roadmaps and first steps by the end of 2026; high-risk use cases migrated by the end of 2030; medium-risk use cases by the end of 2035. | Agreed by EU member states |
| Cyber Resilience Act (Regulation 2024/2847) | Products with digital elements must protect data, for example "encrypting relevant data at rest or in transit by state of the art mechanisms"; main obligations apply from 11 December 2027. | Law |
| Germany: BSI TR-02102-1 (2026) | Classical key agreement on its own is recommended only until the end of 2031 (the end of 2030 for very high protection needs). | National guidance |
| France: ANSSI | Hybrid post-quantum cryptography is mandatory for the regulated scope (classified data, Diffusion Restreinte, vital systems); post-quantum requirements for product qualification from 2027; "not reasonable" to buy products without it after 2030. | Mandatory for the regulated scope; guidance otherwise |
| Nordic countries | ||
| Denmark, Finland and Sweden: EU roadmap | Covered by the EU roadmap above: national roadmaps and first steps by the end of 2026, high-risk use cases migrated by the end of 2030, medium-risk use cases by the end of 2035. | Agreed by EU member states |
| Norway: NSM, quantum migration | NSM's position is to switch to quantum-resistant cryptography, and it urges all organisations to meet the quantum threat by 2030. | National guidance |
| United Arab Emirates | ||
| National Encryption Policy (UAE Cyber Security Council) | Mandates encryption controls to secure data at rest and in motion, and defines requirements for key management and post-quantum cryptography. Its stated aim includes the security of organisations and individuals in the UAE that handle critical and personal data. | National policy |
| Saudi Arabia | ||
| NCA Essential Cybersecurity Controls (ECC-2:2024, control 2-8-3) | Government agencies, their affiliated companies, and private entities that own, operate or host critical national infrastructure: cryptography must meet at least the National Cryptographic Standards published by NCA. | Mandatory for the entities named |
| NCA National Cryptographic Standards (NCS-2:2025, in Arabic) | Replaces NCS-1:2020. Lists the accepted post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA and Classic McEliece) and states that all cryptographic systems and solutions must support post-quantum algorithms. | National standard that ECC-2:2024 points to |
| Israel | ||
| Bank of Israel, Supervisor of Banks, Letter 202501 (January 2025) | Banks and licensed payment service providers must, at a minimum, map their encrypted information (at rest, in motion with outside parties, and held outside the bank) and create a transition plan to encryption made for the quantum era. An initial preparedness plan, discussed by the board, was due within one year. The letter names the "Harvest Now, Decrypt Later" risk. | Required of Israeli banks and payment service providers |
| Singapore | ||
| Singapore: CSA Quantum-Safe Migration Handbook (July 2026) | CSA asks critical information infrastructure owners to submit quantum-safe migration plans by 31 March 2027; new systems bought from 1 January 2028 should support quantum-safe algorithms; migration complete by 31 December 2031. | Official guidance for critical information infrastructure owners |
Most of these rules bind government bodies and their suppliers; check which apply to you. This is a summary, not legal advice. QNSQY's free scan produces the cryptography inventory these discovery steps ask for (a CycloneDX CBOM and the OMB M-23-02 report), and QNSQY encrypts data at rest with NIST's post-quantum standards. The CNSA 2.0 edition is built for national security systems; it is not released yet and has no NSA approval.
02
The threat is already here
Nation-state actors are harvesting encrypted data today, waiting for quantum computers to break it tomorrow.
This is called Harvest Now, Decrypt Later.
Medical records. Legal documents. Financial data. Trade secrets. Everything encrypted with RSA or ECDH today becomes readable once quantum computers arrive, whether it lives on a laptop, in a database, on backup tape, or in a cold-storage archive.
Sensitive data needs protection that lasts decades, not years, across every layer it touches.
2026
HARVESTING
203X
Q-DAY
Q-Day: The moment a cryptographically-relevant quantum computer becomes operational. Most estimates place it within the next 10-15 years.
03
The solution is simple
B
Local-Only by Design
File content, passwords, and private keys never leave your device. Works fully offline for file operations. The only network traffic is encrypted billing metadata to billing.quantumsequrity.com, pinned there by application-layer controls (pinned DNS + TLS 1.3 + PQC envelope); on Linux CLI, seccomp-bpf then kills ALL network syscalls before any crypto operation (seccomp cannot filter by host). Windows and GUI: use a physical air-gap for the strongest isolation.
C
Zero-Knowledge Architecture
No account needed for the free basics (password encryption, ML-KEM-512, ML-DSA-44). No cloud storage of your files. We never see your passwords, your files, or your encryption keys. Everything happens locally.
D
Memory-Hard Key Derivation
Uses Argon2id (OWASP recommended) for password hashing. Every password guess costs real memory, so cracking with GPUs and ASICs is slow and costly.
E
Authenticated Encryption
AES-256-GCM ensures both confidentiality and integrity. Any tampering is detected immediately upon decryption.
F
Per-File Keys
Fresh keys for every encryption, so a key exposed for one file opens no other file. A leaked password or private key still opens every file protected with it.
04
Three editions, one code base
The Standard edition is available now. The Approved Mode and CNSA 2.0 editions are built and tested internally and not released yet. None of them is FIPS 140-3 validated, and the CNSA 2.0 edition has no NSA, NIAP or CSfC approval.
Standard
Available now
For Linux and Windows. Post-quantum encryption (hybrid by default) and signatures for files, folders, backups and archives: ML-KEM with X25519 by default, ML-DSA, SLH-DSA, LMS, FN-DSA and HQC (both pre-standard), AES-256-GCM and Argon2id. Desktop app, terminal app, command line and an MCP server for AI agents. Standard edition
Approved Mode
Not yet released
Approved algorithms only, fixed when the program is built: ML-KEM, ML-DSA, AES-256-GCM, SHA-2, HMAC, HKDF and PBKDF2. Start-up self-tests with an error state, key-pair checks, an SP 800-90A random bit generator and an "Approved service" line for every operation. Preparation for FIPS 140-3; not validated. Approved Mode edition
CNSA 2.0
Not yet released
For defense and national-security users: ML-KEM-1024, ML-DSA-87, AES-256-GCM and SHA-384/512 only. An offline licence, no network use, every file signed, a Crypto Officer role, X.509 trust anchors and a signed audit trail that cannot be switched off. CNSA 2.0 edition
| Standard | Approved Mode | CNSA 2.0 | |
|---|---|---|---|
| Status | Available now | Built and tested internally | Built and tested internally |
| Key exchange | ML-KEM + X25519 (hybrid) | ML-KEM-512/768/1024 | ML-KEM-1024 |
| Signatures | ML-DSA, SLH-DSA, LMS, FN-DSA | ML-DSA-44/65/87 | ML-DSA-87, every file signed |
| Licence and network | Online plan check | Online plan check | Offline licence, no network |
| Start-up self-tests | Program integrity check | Self-tests and integrity test | Self-tests and integrity test |
| Certification | None | Not FIPS 140-3 validated | Not validated; no NSA approval |
Every row, the standards each edition follows, and the limits: compare the three editions.
05
How it works
01
Select
Point QNSQY at any data you hold: documents, databases, backups, or archival cold storage.
02
Encrypt
One command. Enter your password. QNSQY handles the rest with quantum-safe hybrid algorithms.
03
Store
The resulting .qs output is designed to resist both classical and quantum attacks, at rest or in transit.
04
Decrypt
When you need access, decrypt with your password. Integrity verified automatically.
For organizations migrating databases, replication streams, or long-retention cold storage off classical cryptography, QNSQY offers scoped professional services (readiness assessment, DB migration, cold storage PQC, migration-as-a-service). See Pricing.
06
Proof, not promises
Every claim on this page is backed by a test we run or a published standard; the test results are on the Validation page. No testimonials, no fabricated logos, no invented numbers.
Known Answer Tests
17 KAT modules cross-checked against NIST ACVP, FIPS, and RFC reference vectors.
Covers ML-KEM, ML-DSA, SLH-DSA, HQC, FN-DSA, LMS, AES-GCM, XChaCha20, Ed25519, X25519, Argon2id, HKDF-SHA3, HMAC, SHA-2, SHA-3, BLAKE3 and Shamir secret sharing.
Official NIST and IETF reference vectors
3,300+ cases exercised against vectors from NIST ACVP, NIST CAVP, NIST FIPS publications, and IETF RFCs. Includes ML-KEM (240), ML-DSA (285), SLH-DSA (372), AES-128-GCM (45), AES-256-GCM CAVP (100), HMAC (1,950), SHA-2 / SHA-3 (~620), Ed25519 (54), and BLAKE3 (105).
44 vector files. HQC and FN-DSA are checked by round-trip and tamper-rejection tests, not by NIST vector replay.
NIST ACVP-Server full replay
19,769 / 0
vectors pass / fail against ACVP-Server v1.1.0.43 (commit 975de31eb83d87), replayed against the open-source libraries QNSQY ships (September 2026 sweep). 100.00% non-skipped pass rate. 36 of 55 algorithm directories at 100% NIST coverage: HMAC (all 22 dirs), ML-KEM keyGen + encapDecap, ML-DSA keyGen + sigGen + sigVer, SLH-DSA (all 12 parameter sets), SHA-2-256 / 512 / 512-256, SHAKE-128 (FIPS 202). 11,302 documented skips. Not FIPS 140-3 / CMVP certification (on the roadmap).
Reproduce it with the standalone harness on the Validation page (no QNSQY source needed). Write-up: NIST ACVP test sweep.
Algorithms actually wired up
ML-KEM-512/768/1024, ML-DSA-44/65/87, SLH-DSA (6 parameter sets), FN-DSA-512/1024, LMS, HQC-128/192/256, X25519, Ed25519, AES-256-GCM, XChaCha20-Poly1305, Argon2id, HKDF-SHA3-256, BLAKE3.
Standards: FIPS 203, 204 and 205 and SP 800-208; FN-DSA (FIPS 206, not yet published; pre-standard Falcon implementation) and HQC (selected by NIST, not yet published as a standard).
Source available on request
The source code is private. We share read access with customers, integrators and auditors under a non-disclosure agreement.
Request read access through the contact form.
Native builds for Linux and Windows
OS-native packages for Linux (DEB, RPM) and Windows (an installer and a portable .exe). Each release ships SHA-256 checksums signed with ML-DSA-87, and the program has the release public key built in, so qnsqy verify-release can check a download. Windows installers are not yet code-signed. macOS builds are not available yet.
Direct downloads on the Download page; how to check them in the signing procedure.
Measured speed
The shipped program (September 2026 release), timed on one laptop-class machine: 184 MB/s to encrypt a 1 GB file with ML-KEM-768 + X25519 and AES-256-GCM, 215 MB/s to decrypt it.
Measured on real hardware and published with the raw data on the Validation page.
Independent audit: not yet
No independent firm has audited QNSQY yet. Our security reviews so far are internal and automated.
What is and is not certified: Certifications.
Pinned dependency graph
Every dependency is pinned to an exact version and checksum. Bit-for-bit reproducible release binaries are on the roadmap, not in place yet.
Each release ships a CycloneDX software bill of materials of its dependencies, covered by the signed checksums.
07
Built on open standards
Public, peer-reviewed cryptographic standards. No security through obscurity. No proprietary algorithms.
Hybrid KEM
ML-KEM + X25519
FIPS 203 lattice-based, all tiers
Hybrid Signatures
ML-DSA + Ed25519
FIPS 204 lattice-based, defense-in-depth (Pro+; Free signs with pure ML-DSA-44)
NTRU Signatures
FIPS 206 not yet published (pre-standard); compact signatures (Business)
Hash-Based Signatures
SLH-DSA
FIPS 205 stateless (Pro+)
Password Hashing
Argon2id
OWASP recommended, memory-hard
Network Access
Licence check when signed in
During each operation QNSQY blocks its own network on Linux, and on Windows when run as administrator (not as a standard user). Remote backup, if you set it up, sends ciphertext only
Memory-hard password hashing
Authenticated encryption
Per-file keys
Tamper detection
Files never uploaded
Approved-mode and CNSA 2.0 builds: built and tested internally. Not yet released.
The approved-mode build allows approved algorithms only. The CNSA 2.0 build narrows it to the CNSA 2.0 algorithms, with an offline license and no network use. The full Windows 11 test is still in development. 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. What each build allows and refuses, and the roadmap.
08
Simple, transparent pricing
Free
For trying post-quantum encryption on your own files.
$0forever
Not a trial. No time limit.
- Algorithms
- ML-KEM-512, ML-DSA-44
- File size
- No limit with ML-KEM-512
- Tools
- Encrypt, sign, verify, shred, PQC scan
- Use
- Personal use only
- Support
- Documentation
Pro
For one professional protecting work files.
$29per month
or $290 a year
$290per year
Billed yearly. You save $58.
- Algorithms
- All ML-KEM and ML-DSA levels, plus SLH-DSA
- File size
- No limit up to ML-KEM-768, 25 GB with ML-KEM-1024
- Tools
- Free tools plus batch jobs, password vault, rekey, audit log
- Use
- Personal and commercial, one person
- Support
Business
Best for teamsFor teams that handle regulated or client data.
$49per user, per month
or $490 per user a year
$490per user, per year
Billed yearly. You save $98 per user.
- Algorithms
- Every algorithm, adding FN-DSA, HQC and LMS
- File size
- No limit
- Tools
- Pro tools plus SSO, signed policy, key escrow, M-of-N approvals
- Use
- Commercial, priced per user
- Support
- Priority email, 24-hour response
Enterprise
For organizations and agencies that need one contract.
Contact us
Pricing depends on scope.
- Algorithms
- Every algorithm
- File size
- No limit
- Tools
- Everything in Business, plus government builds
- Use
- Whole organization, under contract
- Support
- Signed SLA, onboarding, named contact
Prices in US dollars, excluding tax.
09
Services
Beyond the CLI: end-to-end PQC migration services. Scoped engagements, written deliverables, no retainers.
PQC Readiness Assessment
Fixed-scope 2 to 4 week discovery powered by qnsqy scan. Risk-ranked inventory, HNDL exposure, CNSA 2.0 and NIST IR 8547 gap map, remediation roadmap with estimates.
Migration as a Service
File-tree PQC migration powered by qnsqy migrate. Atomic, resumable, rollback-safe. Discovery, design, implementation, validation, and handover.
Database Migration to PQC
In-place TDE and key-wrapping migration for PostgreSQL, MySQL, Oracle, SQL Server. Pilot waitlist open. Today, DB key-material discovery is handled by the Readiness Assessment.
Cold Storage PQC
Re-envelope the key material on long-retention archives. Tape, S3 Glacier, Azure Archive. Pilot waitlist open. Today, manual re-envelope workflows are covered under MaaS.
10
Quick start
Encrypt a file
# Encrypt (prompts for password) $ qnsqy encrypt -i secret.pdf # Output: secret.pdf.qs # Encrypt with compression $ qnsqy encrypt -i largefile.tar -z # Output: largefile.tar.qs (compressed)
Decrypt a file
# Decrypt (prompts for password) $ qnsqy decrypt -i secret.pdf.qs # Output: secret.pdf (original restored)
Securely delete original
# 3-pass secure delete $ qnsqy shred secret.pdf # File overwritten and deleted
11
Why QNSQY?
| Feature | QNSQY | 7-Zip | GPG | VeraCrypt |
|---|---|---|---|---|
| Post-quantum safe | Yes | No | No | No |
| Memory-hard KDF | Argon2id | PBKDF2 | S2K | PBKDF2 |
| Large file streaming | Yes | Limited | No | Yes |
| Authenticated encryption | Yes | Yes | Yes | Yes |
| Digital signatures | ML-DSA | No | RSA/ECDSA | No |
| Network Blocked* | Linux CLI | No | No | No |
| Works Offline | Yes | Yes | Yes | Yes |
12
Common questions
Quantum-safe encryption uses algorithms designed to resist attacks from both classical and quantum computers. QNSQY uses a hybrid approach combining post-quantum (ML-KEM, ML-DSA, SLH-DSA) with classical algorithms (X25519, Ed25519) using AND construction, so attackers must break BOTH to succeed. This provides defense-in-depth against both quantum and classical threats. All algorithms are NIST-standardized (FIPS 203/204/205).
Your files cannot be recovered. This is by design. QNSQY uses zero-knowledge architecture: we never see your password and have no way to recover encrypted files. We recommend keeping secure backups of critical passwords. Business tier users have optional key escrow features for organizational recovery scenarios.
For quantum resistance, yes. 7-Zip and GPG use traditional cryptography that quantum computers will eventually break. QNSQY specifically addresses this threat with NIST-approved post-quantum algorithms. Additionally, QNSQY uses Argon2id for key derivation (more resistant to brute-force than the older algorithms used by 7-Zip and GPG) and provides authenticated encryption with tamper detection by default.
Encryption, decryption, signing and verification run on your device and work offline. What goes over the network: when you are signed in, QNSQY checks in with billing.quantumsequrity.com before an operation, sending the operation type, the data size, the algorithm and the program version, never file names or contents, and afterwards whether it succeeded and how long it took; the answer is cached, so you can keep working offline for up to 7 days. Remote backup (push, pull, sync), if you set it up, sends only ciphertext to the storage you choose. On Linux, after that check, seccomp-bpf blocks every network call at the kernel before any cryptographic work, including operations started from the desktop app, which run in a separate command-line process. seccomp cannot filter by host, so the check-in itself is pinned to billing.quantumsequrity.com by application-layer controls. On Windows, run as administrator, a firewall rule blocks QNSQY's outbound traffic during each operation; otherwise, disconnect the network for a true air gap. There is no macOS build yet.
QNSQY runs on Linux x86_64 and Windows 10 (1809+) / 11 x86_64. The last full distribution test ran on the shipped program of August 2026, in containers, with identical output on 18 distributions, among them Ubuntu 22.04 / 24.04 / 24.10 / 25.04 / 25.10, Debian 12 / 13, Fedora 40-44 and AlmaLinux 10. Install via npm, the apt or dnf repo, or a direct .deb / .rpm / Windows installer (.exe) download. Requires glibc 2.35+ on Linux; RHEL 10 (same glibc 2.39 as AlmaLinux 10) works, but RHEL / Rocky / AlmaLinux 9 ship glibc 2.34 and are not supported. macOS and Linux ARM64 builds are not yet available.
13
Learn the cryptography
Plain-language deep dives on the algorithms, threats, and standards behind post-quantum encryption.
What is post-quantum cryptography?
The full story: why RSA and ECC break, what NIST standardized, and how PQC actually protects data today.
CRQC: what it means
Cryptographically Relevant Quantum Computer, defined. Qubit thresholds, gate fidelity, and realistic timelines.
Hybrid encryption explained
Why every serious PQC deployment combines a lattice KEM with X25519, and what happens if either side fails.
ML-DSA vs SLH-DSA
Lattice signatures versus hash-based: speed, size, assumptions, and when to pick which for your threat model.
Implementing PQC in your org
Step-by-step migration playbook: inventory, risk-rank, pilot, roll out. Avoids the common rewrite trap.
NIST FIPS 203, 204, 205, 206
A guided tour of the four post-quantum standards: scope, parameters, test vectors, and what they don't cover.
Q-Day: when quantum breaks encryption
What actually happens the day a CRQC arrives, who is exposed first, and which workflows must shift before then.
State of PQC in 2026
Where vendors, regulators, and standards bodies stand right now. Adoption numbers, gaps, and what to watch next.
Your data. Yours.
Not your cloud provider's. Not your government's. Not ours. Take control with post-quantum encryption across every layer: laptops, databases, and cold storage.