QNSQY validation: nine independent, reproducible evidence streams. 18,703 NIST vectors through the shipped crates and 18,800 through QNSQY's own code, 0 fail; 2.79 billion fuzz executions; 6 machine-checked formal proofs.

Nine independent evidence streams

Cryptographic assurance is established through nine independent, reproducible evidence streams, alongside the current third-party-certification status. The first two answer different questions and are deliberately kept separate: stream 1 proves the upstream algorithm libraries QNSQY ships are correct, stream 2 proves the code QNSQY wrote around them is correct. Each is summarized below and tabulated in the assurance summary; full method and raw logs are in the numbered sections.

Sweep Summary

QNSQY replays NIST's official ACVP test vectors against the exact upstream Rust crate versions its binary links. The harness drives those crates directly and contains no QNSQY code, so this establishes that the algorithm implementations QNSQY depends on are conformant; it does not, on its own, exercise QNSQY's integration of them. The latest sweep, dated 2026-06-03, against ACVP-Server v1.1.0.42 (commit 15c0f3deeefbfa8cb6cd32a99e1ca3b738c66bf0):

Project Wycheproof adversarial vectors

The ACVP sweep above proves QNSQY computes the correct answer on valid input. Project Wycheproof exercises the complementary property: that invalid, malformed, and adversarially crafted inputs are rejected. QNSQY runs Google's official Project Wycheproof v1 adversarial test vectors on every build. The imported corpus holds 3,205 vectors across 15 vector files; roughly 2,937 execute, with zero failures. Each harness fails the build if any valid vector is rejected, if any invalid vector is accepted, or if zero vectors execute, which prevents a vacuous pass.

The vectors exercise the reject paths that matter for security: tampered AES-GCM authentication tags, malleable Ed25519 signatures, malformed public keys, and twisted-curve points. The AES-256-GCM and XChaCha20-Poly1305 vectors test QNSQY's own AEAD code. The 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. The remaining vectors in the imported corpus are skipped because they use parameters QNSQY does not offer, for example AES with 128- or 192-bit keys where QNSQY is 256-bit only; every skip is logged with a reason. Every skip is logged with a reason and none is counted as a pass.

The vectors are Google's Project Wycheproof v1 corpus, fetched verbatim from the public C2SP/wycheproof repository, exercised by four Rust harnesses (one each for AEAD, EdDSA/X25519, ML-DSA/ML-KEM, and HKDF/HMAC). The corpus is public; QNSQY's harness source is proprietary and not shared, so this stream is evidenced by its result, not by an external re-run.

Assurance summary

Cryptographic assurance is not a single score. QNSQY's rests on nine independent, reproducible evidence streams plus its current third-party-certification status. The matrix below states, for each stream, the property it establishes, the measured result, and the prevailing industry benchmark. The ACVP and formal-proof results are independently reproducible from the published artifacts; the remaining streams are evidenced by the raw logs and summaries linked in the numbered sections.

Rows one through nine are each backed by published artifacts on this page; the NIST ACVP and formal-proof rows are additionally re-runnable by any third party from a standalone harness and runnable prover models, while the others are evidenced by their raw logs and summaries (they run against QNSQY's closed source). The tenth, independent certification, is the control QNSQY does not yet hold; it is stated here alongside the strongest results rather than omitted. The numbered sections below provide the full method and raw logs for each stream, with re-run instructions for the two reproducible streams.

1. Reproducibility

The procedure below reproduces the 18,703 / 0 / 11,259 / 29,962 result line (pass / fail / skip / total attempted) on a clean machine. Realistic end-to-end time on first run is about 30 to 45 minutes: roughly 5 to 15 minutes for the 667 MiB sparse clone of NIST's vectors (network-dependent), 5 to 10 minutes for cargo to download and build the dependency tree, and 10 to 15 minutes for the sweep itself. Subsequent runs (vectors and build cached) are about 10 to 15 minutes. The standalone reproducer harness is published as an archive below; QNSQY's product source is closed.

QNSQY's product source is closed, but the test harness is fully shareable: it depends only on public RustCrypto crates and contains no QNSQY proprietary code, file format, or internal data. We publish the harness as a self-contained archive: qnsqy-acvp-harness-v1.0.tar.gz (SHA-256). It includes the 12 loader modules, the shared Report helper, a Cargo.toml pinned to the exact crate versions QNSQY v7.2.20 ships, and a README. The archive is approximately 28 KB compressed.

Step 1. Stage the NIST ACVP vectors

# Sparse clone the ACVP vector tree at the pinned commit. About 1 GiB on disk.
$ mkdir -p /tmp/acvp-source && cd /tmp/acvp-source
$ git init
$ git remote add origin https://github.com/usnistgov/ACVP-Server.git
$ git config core.sparseCheckout true
$ echo "gen-val/json-files/" > .git/info/sparse-checkout
$ git fetch --depth 1 origin 15c0f3deeefbfa8cb6cd32a99e1ca3b738c66bf0
$ git checkout FETCH_HEAD

Step 2. Download and extract the QNSQY ACVP harness

$ curl -fLO https://quantumsequrity.com/validation-artifacts/qnsqy-acvp-harness-v1.0.tar.gz
$ curl -fLO https://quantumsequrity.com/validation-artifacts/qnsqy-acvp-harness-v1.0.tar.gz.sha256
$ sha256sum -c qnsqy-acvp-harness-v1.0.tar.gz.sha256
$ tar xzf qnsqy-acvp-harness-v1.0.tar.gz
$ cd qnsqy-acvp-harness

# Point the harness at the staged NIST vectors via a symlink.
$ ln -s /tmp/acvp-source/gen-val/json-files tests/acvp_official/acvp-vectors

The archive contains only the test harness source: 12 algorithm-family loaders plus a shared mod. It depends solely on public RustCrypto crates (sha2, sha3, hmac, aes-gcm, ed25519-dalek, x25519-dalek, ml-kem 0.2.3, ml-dsa 0.1.0-rc.7, slh-dsa 0.2.0-rc.1). No QNSQY product code is included or required.

Step 3. Build and run

$ cargo build --release --tests
$ ./target/release/deps/acvp_official-* \
    --nocapture --test-threads 2 \
    2>&1 | tee /tmp/acvp-RUN.log

# Expected final line:
test result: ok. 50 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

# Aggregate totals from the log:
$ awk '/^ACVP_REPORT/ { match($0,/pass=([0-9]+)/,p); P+=p[1] } END {print P}' /tmp/acvp-RUN.log
18703
$ awk '/^ACVP_REPORT/ { match($0,/fail=([0-9]+)/,f); F+=f[1] } END {print F}' /tmp/acvp-RUN.log
0
$ awk '/^ACVP_REPORT/ { match($0,/skip=([0-9]+)/,s); S+=s[1] } END {print S}' /tmp/acvp-RUN.log
11259

The harness pins pre-release versions of several RustCrypto transitive crates (pkcs8 0.11.0-rc.11, signature 3.0.0-rc.10, digest 0.11.2) because the upstream ml-dsa 0.1.0-rc.7 and slh-dsa 0.2.0-rc.1 crates are themselves pre-release and have API breakages against the final 0.11/3.0 releases. Pre-release crate versions can be yanked from crates.io at any time. If cargo build stops resolving in the future, the bundled Cargo.lock in the archive will still pin to known-working SHA-256-locked downloads as long as the registry retains those tarballs; the longer-term mitigation is a vendored copy of the dep graph (planned).

A divergent result indicates one of: drift in an upstream Rust crate, a different ACVP-Server commit, or a defect. Discrepancies should be reported to [email protected].

2. Per-Algorithm Results

Fifty ACVP algorithm directories were attempted in the 2026-06-03 sweep. Thirty-three are at 100% coverage of the NIST vectors they contain. The remainder either contain vectors blocked by upstream crate API gaps or contain variant flavors we do not implement. No directory contains a failing vector.

Of the 18,703 passing vectors, the majority are HMAC (12,375). The post-quantum subset (ML-KEM + ML-DSA + SLH-DSA) accounts for 1,998 vectors, approximately 10.7% of the passing total. Machine-readable per-directory totals: acvp-summary.json / .csv.

By cryptographic family

All 50 directories: filter & sort

Interactive view of every ACVP directory (data from acvp-summary.json). Columns are sortable; results can be filtered by directory name or status. For per-vector detail (tcId + expected/got), see the Raw Sweep Log.

The 33 directories at 100% NIST coverage

Every vector in each of these directories matches NIST's expected output:

• HMAC (22 dirs): HMAC-SHA-1, HMAC-SHA-2-{224,256,384,512,512/224,512/256}, HMAC-SHA3-{224,256,384,512} in both -1.0 and -2.0 ACVP schemas. 12,375 vectors total.
• ML-DSA-keyGen + ML-DSA-sigVer: 75 + 180 vectors across all three parameter sets.
• ML-KEM-keyGen: 75 vectors across all three parameter sets (512, 768, 1024).
• SLH-DSA-keyGen + sigGen + sigVer: 1,248 vectors across all 12 parameter sets and every signatureInterface flavor.
• SHA-2-256 -1.0, SHA-2-512 -1.0, SHA-2-512/256 -1.0: 2,575 vectors. AFT, MCT-alternate, and LDT up to 8 GiB.
• SHAKE-128-FIPS202: 269 byte-aligned single-output vectors.
• XECDH-SSC RFC 7748: 50 X25519 self-consistency pair tests.

The remaining 17 directories contain at least one variant we do not implement. They are not failures; they are deliberate scope decisions or upstream-crate API gaps. Section 3 documents every skip.

3. Skip Catalogue (11,259 Vectors)

Every skip is logged with its algorithm directory and a documented reason. Each category below is justified by a scope decision or an upstream-crate API constraint, listed in descending order of vector count.

3.1 Bit-oriented hash inputs (9,071 vectors)

NIST ACVP defines hash inputs at bit granularity (msgLen not a multiple of 8). The Rust sha2 and sha3 crates accept byte-aligned input only. We did not build a sub-byte feeder because QNSQY never hashes non-octet-aligned messages: every API boundary (CLI, GUI, MCP) takes whole bytes. Vectors where msgLen % 8 == 0 all pass. Affected directories: SHA-2 / SHA-3 / SHAKE bit-oriented variants. Status: out of scope for the byte-aligned API.

3.2 SP 800-56C TwoStep KDA-HKDF (2,000 vectors)

NIST's TwoStep KDF uses a different fixedInfo encoding than RFC 5869 HKDF. QNSQY uses the RFC 5869 construction, which has its own ACVP vectors that pass. TwoStep is unused. Status: unused construction.

3.3 ML-KEM EncapsKeyCheck / DecapsKeyCheck (60 vectors)

FIPS 203 §7 defines ML-KEM-EncapsKeyCheck and ML-KEM-DecapsKeyCheck for key validation. The ml-kem 0.2.3 crate does not expose these as standalone functions. The crate's own kem.rs:58 carries the comment "Should we verify that the provided `h` value is valid?", acknowledging the gap. Status: upstream crate API gap. We are tracking RustCrypto/KEMs for a fix; we will close this when the crate adds it.

3.4 ML-DSA externalMu + randomized (45 vectors)

ml-dsa 0.1.0-rc.7 exposes raw_sign_mu(mu, rnd) as pub(crate), unreachable from outside the crate. We pass externalMu deterministic via the public path; the randomized variant requires either a public API or an upstream patch. Status: upstream crate API gap. Tracking RustCrypto/signatures.

3.5 AES-GCM tagLen below 96 bits (30 vectors)

aes-gcm 0.10 enforces SP 800-38D §5.2.1.2 minimum tag floor (96 bits) at the type level. NIST publishes vectors at 32, 64, 96, 104, 112, 120, 128 bits; the four sub-96-bit tag lengths are rejected by the crate. QNSQY uses 128-bit tags exclusively. NIST §5.2.1.2-compliant tag-length cases all pass. Status: legacy IPsec/IKE configurations only. Not used by QNSQY.

3.6 XECDH-keyVer cross-protocol (32 vectors)

XECDH-keyVer verifies behavior across X25519/X448 boundaries. QNSQY uses X25519 only. Self-consistency RFC 7748 vectors (XECDH-SSC) all pass. Status: out of scope for X25519-only deployment.

3.7 Ed25519ph + Ed448 (19 vectors)

Pure Ed25519 (RFC 8032 with empty context) passes its ACVP vectors. Ed25519ph (pre-hashed Ed25519) and Ed448 are not used by QNSQY. Status: unused variants.

3.8 SHAKE MCT variable-output (2 vectors)

ACVP defines a Monte Carlo Test for SHAKE with variable output lengths drawn from a state machine. We implement single-output SHAKE, which is what QNSQY uses, at 100% (SHAKE-128-FIPS202 269/269). The 2 MCT variable-output vectors are not implemented in the harness. Status: harness scope, not a correctness gap.

3.9 AES-192 (varies)

QNSQY uses AES-256 only. Any vector group with keyLen=192 is skipped. Status: scope.

Categories add up to 11,259 (9,071 bit-oriented + 2,000 TwoStep HKDF + 60 ML-KEM key-checks + 45 ML-DSA externalMu-randomized + 32 XECDH-keyVer + 30 AES-GCM sub-96-bit tag + 19 Ed25519ph/Ed448 + 2 SHAKE MCT). Every line in acvp-RUN-final.log is grep-able by the substring SKIP: followed by the directory and reason.

4. Other Validation We Run

ACVP is one evidence stream. Independent of the NIST replay, QNSQY runs several other validation programs against every release: a curated test suite, install smoke tests, fuzzing, an own-code vector replay, release verification with application-security suites, formal proofs, timing side-channel measurement, memory-safety checks, and static + supply-chain scanning.

4.1 Curated KAT suite (403 tests)

QNSQY also runs a curated Known Answer Test suite internally before every release; as of v7.2.38 it passes 403 tests across 19 algorithm modules with 0 failures. It complements the ACVP replay above by covering algorithms not in the NIST ACVP catalog (HQC, Falcon, BLAKE3, XChaCha20, Argon2id, Shamir Secret Sharing) alongside official vectors for ML-KEM, ML-DSA, SLH-DSA, LMS, SHA-2, SHA-3, Ed25519, X25519, HMAC, HKDF and AES-GCM, plus determinism, avalanche and stress tests per module.

Coverage honesty: 17 of the 19 KAT modules drive the upstream crates directly, the same scope as the ACVP replay; 2 (HQC and Shamir) drive QNSQY's own code. A broken dependency is still our problem, so we run and publish all of it, but the evidence about QNSQY's own implementation is the own-code replay in 4.5, not this suite. The KAT suite lives in the proprietary source; the ACVP harness in Section 1 is the shareable stream.

4.2 Install + functional smoke test (15 platforms)

Every release is installed from its real package (.deb / .rpm / .exe) and run through an 11-test Free-tier suite (password encrypt+decrypt, SHA round-trip, ML-DSA-44 keygen/sign/verify, ML-KEM-512 recipient round-trip, BLAKE3) plus an 8-test Business-tier suite (FN-DSA-1024, HQC-256, LMS-SHA256-H10W2, SLH-DSA-128s, ML-KEM-1024).

Not supported (glibc 2.34 or older): Debian 11, Rocky 9, AlmaLinux 9. macOS: build pipeline pending.

4.3 Fuzzing (random + hostile input)

Coverage-guided fuzzing exercises parser and crypto code paths with random and adversarially mutated inputs; any crash, hang, or memory error is treated as a finding. QNSQY maintains 43 cargo-fuzz harnesses (32 in the QNSQY core, 11 in qs-chat) covering the .qs header and chunk decoders, the recipient-slot parser, AEAD, KEM, the audit-log chain, the steganography and time-lock extractors, and the qs-chat message/voice parsers; the harnesses live in QNSQY's proprietary source tree, so the published evidence for this stream is the campaign result log, not an external re-run. Coverage is not yet complete: the polyglot, deniable-container and remote-manifest parsers do not yet have fuzz targets, and the suite is not yet wired into CI as a merge gate.

The most recent campaign (2026-08-04, against v7.2.38 build 868cc4e0) ran all 32 core harnesses for one hour each, eight concurrent, seeded from the accumulated corpus: 2,786,827,494 executions with zero crashes in product code. Per-target highlights: the verify path at 435.6M executions, the recipient-key parser at 383.0M, the steganography extractor at 308.4M, the threshold-parameter parser at 303.8M, the time-lock header at 240.8M, the chunk parser at 27.9M, the encrypted-header decoder at 23.7M. The corpus grew from 23 MB to 75 MB over the campaign, so the coverage carried into it compounds on the next run.

The campaign surfaced exactly one crash, and we report it rather than filter it: a four-byte input panics inside the third-party hbs-lms 0.1.1 crate (src/util/helper.rs:6, a slice range check), not inside QNSQY code. It cannot occur in the shipped product: lms_verify wraps that call in catch_unwind and the release profile sets panic = "unwind", so the panic is caught and returned as an error. The fuzzing harness builds with an abort handler that fires before the guard can run, which is why the fuzzer observes it and the product does not. We verified this against the shipped binary: LMS signatures corrupted at three different offsets, plus a hard truncation, all returned a non-zero exit with no crash, no abort and no memory fault. We run these campaigns before releases; wiring them into a public continuous-fuzzing service (OSS-Fuzz) is on the roadmap. The full campaign log is published at fuzz-campaign-v7.2.38.log (SHA-256). The previous campaign, run against v7.2.20 on 2026-06-13 at 180 s per target, is retained unchanged at fuzz-campaign.log so the figures quoted in that release of this page remain verifiable.

4.4 Internal security audit history

QNSQY undergoes multi-agent internal security audits on every major release. We do not publish per-finding detail to avoid telegraphing partially mitigated weaknesses, but we publish the cadence: internal audit rounds since 2026-03 have covered crypto core, billing API, payment API, CLI, and infrastructure on a rolling basis. Findings are tracked internally and remediated prior to release. Independent third-party audit is on the roadmap and not yet engaged.

4.5 Own-code vector replay (NIST vectors through QNSQY's API)

The ACVP sweep at the top of this page drives NIST's vectors into the Rust crates QNSQY ships. That is a real and necessary check, but it is worth being precise about what it proves: it proves those libraries are correct. It says nothing about the code QNSQY wrote around them: the key wrapping, the parameter validation, the format binding, the API surface an attacker actually reaches. A vendor can pass every ACVP vector and still get its own integration wrong.

So we replay the same NIST corpus a second time, through QNSQY's own entry points instead of the crate's. As of v7.2.38, 18,800 NIST vectors run through QNSQY's own code, all passing: ML-KEM keygen/encap/decap, ML-DSA keygen/siggen/sigver (with and without context), SLH-DSA keygen/siggen/sigver across all twelve parameter sets, LMS sigver, X25519 keygen and shared-secret computation, pre-hash mode, key validation, and the hash and HMAC corpora. By family: hash 4,191; HMAC 12,375; ML-KEM 180; ML-DSA 210; SLH-DSA 456; LMS 80; X25519 35; pre-hash 591; internal-interface 606; key validation 76. Most corpora drive the qnsqy_core library API; the hash corpus is driven through the compiled qnsqy CLI binary itself, which exercises argument parsing and chunked reads on top of the hasher.

Where deterministic replay requires fixing the randomness, seeded interfaces (generate_keypair_seeded, encapsulate_seeded, generate_signing_keypair_seeded, sign_data_seeded) exist for exactly this purpose and are compiled out of shipping builds; a dedicated 11-test suite runs with default features and proves the gate holds, including that no shipping feature reaches the seeded code and that production key generation still draws from the system RNG. Verification-side suites (sigver, key validation) and X25519 public-key derivation consume no randomness and run through the ordinary public API.

Where a vector cannot be driven through our API we exclude it and record the reason in the corpus file rather than quietly dropping it. As of this sweep, 9,414 vectors are excluded, in three families: bit-oriented hash inputs and outputs (9,123: messages or XOF output lengths that are not a whole number of bytes, which a byte-oriented API cannot express), LMS modes QNSQY does not ship (240: SHAKE variants and M24 parameter sets), and Curve448 (51: not implemented). NIST's signatureInterface=internal vectors are not excluded: all 606 replay through the same gated, non-shipping entry points described above, and the corpus ledger cross-references them explicitly rather than double-counting them as excluded. Each exclusion is a documented design boundary, not a gap we are hiding.

One subset deserves a specific note, because it runs without any test-only feature flag at all: FIPS 204's deterministic ML-DSA variant fixes the per-signature randomness to zero, which is exactly what QNSQY's shipping sign_data and sign_data_with_context do, so those vectors replay straight through production code in a default build. Coverage that runs by default is worth more than coverage behind a flag no build sets.

Artifacts: the per-corpus vector counts and the full exclusion ledger are published at own-code-vectors-v7.2.38.txt (SHA-256). Artifacts published for the previous release (v7.2.20, sweep dated 2026-06-03) are retained verbatim under /validation-artifacts/archive/2026-06-13/ rather than overwritten, so any figure this page has ever quoted stays checkable.

4.6 Release verification (automated suites, CLI acceptance, application security)

Every release ships only after a verification sweep against the exact release build; for v7.2.38 that is build 868cc4e0, binary SHA-256 c7e22265953fbf87b3e110374e28fb7025701a82a4f10b6038c4ef306906f3dc, tested as the installed package, not from the build tree. Three layers, counted separately:

• Automated suites: 2,038 tests across 62 suites, 0 failures. Of the 62 suites, 51 exercise QNSQY's own code, 4 replay official vectors against the upstream crates only (the ACVP and three Wycheproof harnesses), and 7 are self-contained consistency checks of constants and replicated logic. We publish the split rather than one blended number, for the same reason Section 4.5 exists. Two runs are excluded from the headline count, a duplicate library run and one suite invoked with the wrong feature flag; both exclusions lower the total, and the artifact states them so the arithmetic can be checked.
• CLI acceptance: a 1,392-operation end-user run against the installed package, covering all 54 commands, all 66 subcommands, and all 115 long command-line flags with recorded exit codes and evidence per operation. Eight flag probes whose first invocations were malformed by the harness were re-run corrected and recorded additively; the two state-destroying commands (logout, reset-state) were exercised against an isolated profile so the live session was never at risk.
• Application security (billing API): 24 test files, 701 passing tests, 8 marked todo. QNSQY's cryptography runs locally; the one networked service is the billing and account API, so it carries its own suite, including control-mapped files: OWASP ASVS 5.0.0 across six files and 288 tests (Level 1 core 95; L2/L3 authentication, session and authorization 48; configuration and cryptography 46; web and logging 46; formerly-open gaps now closed 39; N/A-condition guards 14), NIST SP 800-53 Rev 5 (31), NIST SP 800-63B (25), PCI-DSS v4.0 (21), HIPAA Security Rule technical safeguards (30), GDPR (7), SOC 2 Trust Services Criteria CC6/CC7 (32), and CNSA 2.0 / FIPS algorithm mapping (28). The 8 todo entries are known, tracked gaps stated in the suite itself rather than deleted. Scope: these cover the billing Worker; the payment processor has its own separate suite, not counted in these numbers.

Artifacts: per-suite results, the exclusion arithmetic, and the billing-API summary are published at test-suites-v7.2.38.txt (SHA-256).

4.7 Formal verification (machine-checked proofs)

Testing demonstrates correct behavior on the inputs exercised; symbolic and computational verification establish security properties over the entire input space under a defined attacker model. QNSQY's security-critical protocols were modeled in symbolic (ProVerif, Tamarin) and computational (CryptoVerif) provers under Dolev-Yao and game-based adversaries respectively. These are proofs about the protocol abstractions (hand-written models), not about the shipping Rust implementation; there is no automated model-to-code link. Six properties came back proven (no attack exists):

• Your account key stays secret and a subscription token cannot be forged (billing channel). Proven
• When you share a file with several people, an outsider with none of their keys learns nothing (multi-recipient). Proven
• A malicious cloud-backup server cannot tamper with or swap your backup undetected. Proven
• That same server cannot roll you back to an older backup to undo your changes (anti-rollback). Proven
• In secure chat, past messages stay safe even if a long-term key is later stolen (forward secrecy). Proven
• The encryption layer rejects forged ciphertext (AEAD integrity, proven computationally). Proven

Properties were verified with ProVerif 2.05 (4), Tamarin 1.12.0 (1), and CryptoVerif (1, integrity). Two properties remain open and are not claimed as proven: (1) Post-compromise security of the chat ratchet. A ProVerif model (ratchet_pcs.pv) does close a self-healing query, but only under an assumption that does not match the shipping protocol: it signs every new ratchet public key with the parties' long-term identity keys, whereas qs-chat (like Signal's Double Ratchet) leaves ratchet public keys unsigned and authenticates them through the symmetric key chain. Identity-key signing is strictly stronger than chain-key authentication, so that model proves an easier variant, not the deployed ratchet; the Tamarin model of the property did not converge. We therefore list PCS as open. (2) IND-CPA confidentiality of the symmetric cipher: the CryptoVerif secrecy query did not resolve, a known limitation of the symmetric-encryption model that hides content but not plaintext length (AEAD integrity, INT-CTXT, is proven). Both are tracked, and the runnable models, including the non-faithful PCS model, are published so the work can be checked and extended.

Reproducibility: the proof models and raw prover output are published as qnsqy-formal-proofs-v1.tar.gz (SHA-256), with the individual .pv / .spthy / .cv files and a README under /validation-artifacts/formal/. They contain only protocol abstractions and prover results; no QNSQY source, file-format internals, or findings are included.

4.8 Side-channel resistance (timing)

If a secret-dependent operation, such as comparing an authentication tag or a hash, exhibits secret-dependent execution time, an adversary measuring that time can recover the secret incrementally. The defense is constant-time code whose execution time is independent of the secret data. QNSQY's secret comparisons use the audited subtle crate, and we measured the running binary with dudect, a statistical timing-leak detector. All four constant-time functions (compare, compare-fixed, is-zero, select) showed no detectable timing leak (max |t|-statistic 1.5–2.3, well under the conventional dudect leak threshold of ~10). This was measured on a shared developer machine; a formal sign-off would re-run it on dedicated hardware with CPU frequency scaling disabled, which is the standard final step. The raw bench log is published at dudect-sidechannel.log.

4.9 Memory safety

The single biggest source of security vulnerabilities across the industry (roughly 70% of CVEs at major vendors) is memory-corruption bugs: buffer overflows, use-after-free, and similar. The most effective defense is a memory-safe language. QNSQY is written in Rust, which makes that entire class impossible in normal ("safe") code. The places that must use low-level unsafe blocks (for the OS sandbox and the C cryptography libraries) were audited one by one: all 189 blocks. The Rust undefined-behavior checker (miri) ran cleanly over the pure-Rust safe-math / overflow-protection module (11 tests; the 291 tests that call into C cryptography are outside miri's reach and were not covered). To cover what miri cannot reach, an AddressSanitizer build exercised the real cryptographic FFI: 13,248 NIST ACVP vectors across 32 algorithm modules (ML-KEM, ML-DSA, SLH-DSA, AES-GCM, EdDSA, SHA-2/3) executed with zero AddressSanitizer errors and zero failures (the run was time-capped before the remaining modules).

The unsafe-block audit identified low-level soundness/UB defects, 10 higher-risk and 26 medium-risk items, including an aliasing-UB pattern in the ML-KEM shared-secret zeroization, a 128-byte over-read extent in the binary-integrity self-check, and a repr(transparent)-assumption issue in the (not-yet-enabled) HSM path. None has been demonstrated as a working memory-corruption exploit on the shipping Linux build, and the more serious out-of-bounds cases are confined to the HSM feature that is not yet enabled. As of 2026-06-15 the priority shipping-path items are remediated and compile-verified (the ML-KEM aliasing-UB and the integrity read-extent), the HSM forward handle conversion was rewritten to remove the repr assumption, and the remaining items (HSM reverse conversion, blocked by an upstream PKCS#11 API gap; error-path cleanup; a Windows protect-size case) stay tracked. This is not a claim of verified soundness across all unsafe blocks. A sanitized summary (severity counts, categories, and remediation status; exact locations and proof-of-concept inputs withheld) is published at memory-safety-summary.txt.

4.10 Static analysis & supply chain

Two more automated streams run continuously. Static analysis (Semgrep, with the Rust, TypeScript, secrets, and OWASP rule packs) scans the source for risky patterns; the latest run reported zero high- or critical-severity issues (292 informational results, the bulk being an inventory of the audited unsafe blocks); the severity summary is published at semgrep-summary.txt. CodeQL (GitHub's semantic code analyzer, security-and-quality query pack) was additionally run over the billing-API TypeScript (94 files): 0 error- and 0 warning-severity results, with 22 note-level (the lowest tier) advisories, namely ReDoS-class input-validation regexes (bounded by Cloudflare Workers' CPU and request-size limits) and three intentional SIEM audit-log lines; the summary is published at codeql-billing-api-summary.txt. The supply-chain and secret scanning runs on every build; the complete results are reported below:

• Dependencies (cargo-audit / cargo-deny): 0 exploitable CVEs, but the advisory gate currently fails non-zero on 8 unmaintained + 2 unsound transitive crates, notably the archived-upstream pqcrypto-* bindings. Separately, the build still depends on pre-1.0 release-candidate ml-dsa / slh-dsa crates (no advisory against them, but not yet at a stable release). The full advisory list is published at dependency-advisories.txt.
• npm dev-toolchain: npm audit reports 1 critical + 3 high advisories in build-time tooling (esbuild / vite / wrangler / undici) with no upstream fix. These are dev-only and not part of the shipped Rust binary; the shipped Rust binary and its scoped optionalDependency wrapper carry no affected runtime dependencies.
• Secret scanning (gitleaks): runs automatically on every build of the source tree. By design the client holds no server-side secrets: every cryptographic operation runs locally, and the only key material the binary embeds is the public release-verification key.
• SBOM: a full software bill of materials of all 579 dependencies is published at sbom-crates.txt.

5. Limitations and What This Does Not Prove

The following items bound the scope of the evidence presented above.

6. References

NIST standards QNSQY implements

• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), August 2024
• FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA), August 2024
• FIPS 205: Stateless Hash-Based Digital Signature Algorithm (SLH-DSA), August 2024
• FIPS 180-4: Secure Hash Standard (SHA-2)
• FIPS 202: SHA-3 Standard (SHA-3, SHAKE)
• FIPS 198-1: Keyed-Hash Message Authentication Code (HMAC)
• SP 800-38D: AES-GCM
• SP 800-208: Stateful Hash-Based Signatures (LMS)
• NIST ACVP Project
• NIST CMVP (Validated Modules list)

IETF specifications

• RFC 7748: X25519 / X448
• RFC 8032: Ed25519 / Ed448
• RFC 5869: HKDF
• RFC 4231: HMAC-SHA2 Test Cases
• RFC 9106: Argon2 (Argon2id)

Source links

• usnistgov/ACVP-Server (canonical NIST vector tree; pinned commit 15c0f3deeefbfa8cb6cd32a99e1ca3b738c66bf0)
• qnsqy-acvp-harness-v1.0.tar.gz (the standalone reproducer; 12 loader modules + 50 test functions; SHA-256 checksum)
• qnsqy-formal-proofs-v1.tar.gz (formal-verification models + prover output: ProVerif, Tamarin, CryptoVerif; SHA-256; individual files under /validation-artifacts/formal/)
• acvp-RUN-final.log · acvp-summary.json · acvp-summary.csv
• own-code-vectors-v7.2.38.txt (per-corpus counts + exclusion ledger) · test-suites-v7.2.38.txt (per-suite results + billing API) · fuzz-campaign-v7.2.38.log (per-target executions + crash disclosure); each with a .sha256 alongside
• /validation-artifacts/archive/2026-06-13/ (v7.2.20-era artifacts, retained verbatim)
• QNSQY-ACVP-Validation-Report.pdf · Markdown source
• Blog: NIST ACVP test sweep, 18,703 vectors and zero failures
• Security page summary

QNSQY's product source is proprietary and not shared. The artifacts above (NIST vectors + standalone harness + raw log + summaries + report) let any auditor verify the algorithm-correctness claims without access to QNSQY's repository.

7. Contact

For security issues, vulnerability reports, or questions about the validation methodology:

• Security: [email protected]
• General: [email protected]
• Sales / procurement: [email protected]
• NIST coordination: please reference the ACVP-Server commit 15c0f3deeefbfa8cb6cd32a99e1ca3b738c66bf0 and link the PDF report in correspondence.

GPG key for security correspondence: see /.well-known/security.txt. We aim to acknowledge security reports within 72 hours.