10.3 crypto-core
One Rust core beneath every platform.
The source-published Rust library beneath every QERYX platform: ML-KEM-1024, ML-DSA-87, X25519, and ChaCha20-Poly1305 behind a single FFI surface.
- FIPS 203
- FIPS 204
- CNSA 2.0 — asymmetric core conformant (R-1 scoping)
- KEM ML-KEM-1024
- Signatures ML-DSA-87
- Hybrid X25519
- AEAD ChaCha20-Poly1305
- KDF HKDF-SHA512
- Password KDF Argon2id
01 / THE CORE — LETTERED
Run the same core on every device and compare the bytes.
One core, every platform
iOS, Android, and the backend link the same Rust crate behind a single FFI surface. No platform implements cryptography outside the library, so a review of this one crate is a review of the whole fleet. Wire-stable test vectors pin every byte-format boundary; the same known-answer battery runs on the phone and on the server.
The FIPS boundary
The module lifecycle is PowerUp → SelfTest → Operational |
Error. At boot, a power-on self-test runs pinned known-answer tests
for ML-KEM-1024, ML-DSA-87, ChaCha20-Poly1305, AES-256-GCM,
HKDF-SHA512, SHA-256, SHA3-256, and X25519 — each output compared
byte-for-byte against a pinned reference, because a self-consistent
but wrong implementation round-trips with itself. Every primitive
entry crosses require_operational(); a failed self-test
denies all cryptographic output.
Algorithm-conformant, not module-validated. ML-KEM-1024, ML-DSA-87 and AES-256-GCM execute in a library whose validated configuration is not the one we link; ChaCha20-Poly1305, HKDF-SHA-512, X25519 and the hash functions execute in separate audited implementations. Every primitive passes a pinned known-answer test at every launch of the app and every start of the relay, and a failed test stops the process. No QERYX module holds a FIPS 140-3 certificate.
Side channels
Every key comparison goes through constant-time equality
(subtle::ct_eq). ML-KEM implicit rejection always runs
the full decapsulation path. ML-DSA-87 signing is hedged per FIPS 204 Appendix D. A fixed-versus-random test-vector leakage assessment — Welch t-tests over ML-KEM-1024 encapsulation and decapsulation, ML-DSA-87 signing and verification, AEAD seal and open, HKDF-SHA-512 expansion, and X25519 — gates every change to those files against a pinned baseline, and its own harness carries a negative control that must detect a deliberately leaky operation. The AArch64 data-independent-timing wrapper is written and not yet wired to the crypto path. The KyberSlash class of
division-timing leaks is closed — division-free kernels, and zero
unpatched reference-C implementations in the dependency lockfile
(audit notes).
Domain separation, everywhere
Every signature carries a FIPS 204 §5.2 context — the signer wraps the 0x00 || len(ctx) || ctx || M structure a second time, self-consistent between QERYX endpoints and staged for single framing behind a dual-accept window — and every HKDF call a labeled info. The full catalog is normative and lives in one file, crypto-core/src/labels.rs, with a frozen legacy allowlist for a handful of pre-registry literals, listed in the invariant test:
611 registered QERYX- labels,
enforced unique and versioned by the crate's own tests. A key derived
for one purpose cannot be replayed at another.
The hybrid combiner
Session keys ride a NIST SP 800-227 §6.2 concatenation combiner: HKDF-SHA-512 over the ML-KEM-1024 and X25519 shared secrets. The library form pins a fixed-literal salt and binds the recipient's X25519 key and the ML-KEM ciphertext into info; the messenger's own 1:1 root binds the transcript in the salt instead — the recipient's exact bundle fingerprint and both transmitted values. Either primitive failing catastrophically leaves the session on the other.
The construction is X-Wing-style, re-instantiated at ML-KEM-1024. The published X-Wing IND-CCA2 proof applies to the ML-KEM-768 parameter set; we do not claim it at -1024, and the source carries the same caveat.
Zeroization and the FFI edge
Every secret-bearing struct is zeroized on drop. FFI entries catch
panics and return error codes — a crypto failure never unwinds into
the host process. The highest-stakes shared-secret path forbids
unsafe at the module level.
Entropy and the signed inventory
Seed entropy aggregates remote quantum-entropy providers — three are wired, and each refill's attestation names which answered — plus one local slot that falls back to the OS RNG and names that fallback in its attestation, through a Toeplitz 2-universal extractor with the SP 800-90B continuous health tests — above the classical floor, never in place of it. Every key still bottoms out in the OS CSPRNG, and breaking a session still requires breaking both X25519 and ML-KEM-1024. At build time the core emits Q-Manifest-CBOM: a Cryptographic Bill of Materials, ML-DSA-87 signed and log-anchored — the machine-readable inventory a reviewer starts from.
This is not QKD. Not quantum networking. Not quantum teleportation. We do not violate the no-communication theorem. Above an X25519 + ML-KEM-1024 floor that alone provides confidentiality, a session can fold a Tsirelson-bounded CHSH witness transcript into its key derivation — a deterministic classical co-possession witness, not physical entanglement; security never depends on it.
One crate. Identical bytes. The same known answers at every boot.
02 / THE LABEL CATALOG — IN SOURCE
Read the label catalog in the source
//! # Rules
//!
//! 1. Every label starts with `b"QERYX-"`.
//! 2. Labels are versioned (`-v1`, `-v2`, …); never edit a shipped label.
//! Coining a new variant always means a new suffix.
//! 3. The constants here are the source of truth. Modules that need the
//! same label MUST `pub use crate::labels::FOO;` rather than re-typing
//! the byte literal. This file is the artifact a reviewer checks against
//! iOS `CryptoLabels.swift` to verify cross-platform parity.
/// Hybrid X25519 + ML-KEM-1024 KEX key derivation (NIST SP 800-227 hybrid).
pub const HYBRID_KEX_V1: &[u8] = b"QERYX-HYBRID-v1";
/// Ciphertext-bound hybrid combiner salt (X25519 + ML-KEM-1024).
pub const HYBRID_COMBINER_SALT_V2B_CT_BOUND: &[u8] =
b"QERYX-HYBRID-v2b-CT-BOUND-ML-KEM-1024-X25519";
/// PQ-wrap envelope key (KEK).
pub const PQ_WRAP_V1: &[u8] = b"QERYX-PQ-WRAP-v1";
/// QSEED top-level extraction.
pub const QSEED_V1: &[u8] = b"QERYX-QSEED-v1";03 / THE PRIMITIVES — MASTER TABLE
Check every primitive against the standard that defines it
| Role | Primitive | Standard |
|---|---|---|
| KEM | ML-KEM-1024 (Category V) | FIPS 203 |
| Signatures | ML-DSA-87, hedged signing | FIPS 204 + Appendix D |
| Classical KEX | X25519 | RFC 7748 |
| AEAD (default) | ChaCha20-Poly1305 | RFC 8439 |
| AEAD (NSS suite 0x0002, reserved) | AES-256-GCM | SP 800-38D |
| KDF | HKDF-SHA512 | RFC 5869 |
| Password KDF | Argon2id — vault floor m=128 MiB, t=3, p=4 (device-calibrated upward); relay m=64 MiB, t=3, p=4; local backup m=256 MiB, t=4, p=2 | RFC 9106 |
| Hashes | SHA-512 · SHA-384 · SHA3-256 | FIPS 180-4 / 202 |
| Signature ctx framing | 0x00 || 0x00 || (0x00 || len(ctx) || ctx || M) — the §5.2 structure wrapped once more; single framing staged | FIPS 204 §5.2 |
| Hybrid combiner | HKDF-SHA512 over ss_ML-KEM || ss_X25519 | SP 800-227 §6.2 |
04 / THE STANDING — BY LIBRARY CLASS
Set the core against the library classes it replaces.
| QERYX crypto-core | Classical E2E library | Platform crypto APIs | |
|---|---|---|---|
| Real workloads | |||
| Quantum adversary | Category V lattice primitives, hybrid | Classical curves | Classical |
| Cross-platform drift | One crate, identical known answers | Per-platform ports | Per-OS behavior |
| Boot-time integrity | POST + gated entries | Not included | OS-dependent |
| Timing leakage | ct_eq + DIT + CI timing gate | Varies | Opaque |
| Reviewability | Spec with path:line cites + CBOM + vectors | Partial | Closed |
05 / THE HARD QUESTIONS
Ask what the core does not claim.
Is crypto-core open?
The library is source-published for review. Licenses, the review path, and what is published are documented at /open-source.
Is this FIPS validated?
Algorithm-conformant, not module-validated. ML-KEM-1024, ML-DSA-87 and AES-256-GCM execute in a library whose validated configuration is not the one we link; ChaCha20-Poly1305, HKDF-SHA-512, X25519 and the hash functions execute in separate audited implementations. Every primitive passes a pinned known-answer test at every launch of the app and every start of the relay, and a failed test stops the process. No QERYX module holds a FIPS 140-3 certificate. Test vectors are pinned at every byte-format boundary.
Where does this stand on CNSA 2.0?
CNSA 2.0 — asymmetric core conformant (ML-KEM-1024 + ML-DSA-87 at Category V; SHA-512 at or above the hash floor). The AEAD is ChaCha20-Poly1305 (RFC 8439), a documented deviation; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002. Pre-evaluation checklist (internal self-assessment against the NIAP Common Criteria bar, latest pass 2026-06): 0 algorithm-layer non-conformances, 5 documented deviations; no accredited-laboratory evaluation has begun.
Why hybrid instead of pure post-quantum?
SP 800-227 hybrid discipline: the session key derives from both ML-KEM-1024 and X25519, so either primitive failing catastrophically leaves the session standing on the other.
Why ML-KEM-1024 and ML-DSA-87, not the smaller sets?
Category V is the CNSA 2.0 requirement for national security systems. One binary at the strictest parameter set beats a two-fork ladder — every seeker gets the same core.
Where is formal verification?
Mechanized protocol proofs are on the roadmap. A reviewer gets a source-level specification with path:line citations for every claim, property-based fuzzing of AAD tamper-resistance, and locked wire vectors at every serialization boundary.
What does a reviewer actually get?
The protocol specification with per-claim source citations, the normative label catalog, the signed CBOM, pinned test vectors, and a wire-trace recipe to confirm the bytes match the spec.