State-actor-class reviewer questions, anticipated and answered: why category-5 parameter sets, why hybrid rather than pure post-quantum, why four ratchets rather than two, how the timing side-channel classes are foreclosed, what happens when operator keys are compromised, and where to capture a wire trace you can decode yourself. Each answer is the distillation; each cites the byte-exact chapter.
Why ML-KEM-1024 and ML-DSA-87, not the smaller sets?
CNSA 2.0 requires NIST security category 5 for National Security
Systems; ML-KEM-1024 and ML-DSA-87 are the
category-5 members of FIPS 203 and 204. QERYX builds one binary for
public and high-assurance deployment, so it compiles to the strictest
requirement once — the bandwidth difference against category-3 sets is
negligible on modern transports. The category-3 signature fallback was
removed outright in 2026-04 after an external audit: no negotiation
variable, no downgrade surface.
Why hybrid X25519 + ML-KEM, not pure post-quantum?
NIST SP 800-227 recommends a hybrid combiner through the migration, and the insurance runs both directions: lattice cryptanalysis is younger than a decade of X25519 deployment, and an unexpected classical break is covered by the lattice side. The combiner derivation binds both shared secrets, both public values, and the protocol version — the handshake paper carries the exact bytes. QERYX does not claim the X-Wing IND-CCA2 proof: that proof is for the -768 parameter set, and the source carries the disclaimer.
Why four ratchets when double-ratchet designs use two?
A classical double ratchet — one DH chain, one symmetric chain — is
fully classical: a cryptographically-relevant quantum computer breaks
all of its past and future output. The
Q-Ratchet keeps both chains and adds
an ML-KEM-1024 chain (the establishment root in revision 1;
100-message epochs activate in revision 2) and an entropy re-injection
chain (revision 2). Classical-only PCS is meaningless against a quantum
adversary; PQ-only PCS is too coarse for per-message claims. The four
interlock to cover both axes.
How are the timing side-channel classes foreclosed?
- The KyberSlash class (IACR ePrint 2024/1049): ML-KEM dispatches to audited secret-independent kernels; the unpatched-reference-C crate that carried the vulnerability was removed from the tree.
- Decapsulation always runs the full implicit-rejection path — no early return anywhere on the surface.
- Every secret comparison is constant-time; no exceptions.
- Signing is hedged per FIPS 204 Appendix D — the deterministic variant, vulnerable to fault-injection differentials, is never used on mobile.
Where is formal verification?
Not yet — and the roadmap says so rather than implying otherwise. Later items are a ProVerif model of the handshake (verifying that context framing forecloses cross-protocol replay) and a Tamarin model of the Q-Ratchet post-compromise claims. Until then the assurance is source-level review against the published spec, property-based fuzzing of AAD tamper-resistance and canonicalization, and wire-stable test vectors locked at every byte-format boundary.
Compromise scenarios, answered
| Scenario | Outcome |
|---|---|
| Operator KTS key stolen | equivocation is detectable — two roots signed at the same sequence conflict, and devices gossip the operator-signed root they were served. Recovery is deliberate rather than automatic: the operator key is anchored by a SHA-384 hash compiled into the app, so a replacement key means a new app release |
| Server master key leaked | the at-rest envelope opens for every epoch, retired ones included, because each wrap key re-derives from the master: the leaker reaches the pre-FSOR baseline, ciphertext still under the end-to-end layer, until a rotated master restores the envelope for new rows |
| Endpoint state read once | session re-establishment in revision 1; in revision 2, recovery within 100 messages via a fresh ML-KEM epoch, entropy re-anchor within 5 |
| Removed group member | the next rotation encapsulates only to remaining members — the group paper has the table |
What is the trust anchor?
For you: your own Serpent ID, device-only in the Keychain and never on a wire — your public handle derives from it one-way, and your identity, key-agreement and signing keys are drawn independently on the device, so no one key unlocks another. For operator-distrusted properties: the operator's ML-DSA-87 key, anchored by a SHA-384 hash compiled into the app, with hard failure on mismatch. For server
blindness: no policy at all — the server's inability to break
ML-KEM-1024 + X25519 +
ChaCha20-Poly1305.
Where can I find a wire trace I can verify?
Once QERYX arrives, capture a handshake, a message exchange and a KTS tree-head fetch against a test deployment; each will decode against the published wire layouts, and every signature will verify against the operator key. Wire-stable test vectors — the KTS leaf recipe, the participant blind hash, the pair token — are printed in the papers with their expected outputs. A published directory of fully-canonical wire traces suitable for black-box conformance testing is a named later work item, not yet built.
References
- QERYX Protocol Specification §17 — all twenty questions with citations.
- Known Limitations and Open Work — the gaps a reviewer will ask about next.
- CNSA 2.0 and FIPS Conformance Posture — the compliance mapping behind §1.