10.3 crypto-core
One Rust core beneath every platform.
The open 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 your 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; implemented via a library lineage holding FIPS 140-3 cert #4631; QERYX's own module is not yet CMVP-certified.
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. On arm64 the core runs in data-independent-timing
mode, and a TVLA timing gate (Welch t-tests across primitives) runs
in CI. 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 — framed as
0x00 || len(ctx) || ctx || M — and every HKDF call a
labeled info. The full catalog is normative and lives
in one file, crypto-core/src/labels.rs:
304 registered QERYX- labels at this build,
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-SHA512 over the ML-KEM-1024 and X25519 shared secrets, salted by the concatenated ciphertexts and bound to the public material. 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 four independent quantum-entropy providers through a Toeplitz extractor with SP 800-90B health checks — above the classical floor, never in place of it. 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. We bind a key-derivation function to a verifiable physical measurement no classical adversary can fabricate in advance.
One crate. Identical bytes. The same known answers at every boot.
02 / THE LABEL CATALOG — IN SOURCE
Read the label catalog in the source that ships
//! # 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 (production) | ChaCha20-Poly1305 | RFC 8439 |
| AEAD (NSS suite 0x0002, staged) | AES-256-GCM | SP 800-38D |
| KDF | HKDF-SHA512 | RFC 5869 |
| Password KDF | Argon2id — m=512 MiB, t=2, p=4 | RFC 9106 |
| Hashes | SHA-512 · SHA-384 · SHA3-256 | FIPS 180-4 / 202 |
| Signature ctx framing | 0x00 || len(ctx) || ctx || M | 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, mirrors, and what you can build from it are documented at /open-source.
Is this FIPS validated?
Algorithm-conformant; implemented via a library lineage holding FIPS 140-3 cert #4631; QERYX's own module is not yet CMVP-certified. 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). Production AEAD today is ChaCha20-Poly1305 (RFC 8439), a documented deviation; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002, staged for rollout. Pre-evaluation checklist: 0 non-conformant findings, 3 documented deviations (NIAP ETR, 2026-05).
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. Today you get 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.