Docs · Library
One library holds the keys.
crypto-core is the Rust crate every platform calls through one FFI surface — one implementation, one review, zero per-platform drift.
Read the shape
iOS, Android, and the backend link the same crate behind a single FFI boundary. No platform implements cryptography outside the library. FFI entries catch panics and return error codes — a crypto failure never unwinds into the host process — and every secret-bearing struct is zeroized on drop.
The boot contract
The module lifecycle is PowerUp → SelfTest → Operational | Error. At boot, pinned known-answer tests run for ML-KEM-1024, ML-DSA-87, X25519, HKDF-SHA-512, SHA-256, SHA3-256, ChaCha20-Poly1305 and AES-256-GCM — eight, with a software integrity self-test last. Every primitive entry crosses an operational gate; a failed self-test denies all cryptographic output.
Respect the label registry
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 registry holds
611 registered QERYX-
labels1,
enforced unique and versioned by the crate's own tests. A key
derived for one purpose cannot be replayed at another.
// Every derivation is domain-separated by a registered label.
// crypto-core/src/labels.rs is the single source of truth; modules
// import the constant — re-typing the byte literal is forbidden.
/// 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";Check the parameters against spec
| 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 |
| Hybrid combiner | HKDF-SHA512 over ss_ML-KEM || ss_X25519 | SP 800-227 §6.2 |
The hybrid 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.
Audit the side channels
Every key comparison goes through constant-time equality. 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.
Entropy, above the classical floor
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.
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.
05The hard questions — asked of the library itself
Ask the hard ones.
Is crypto-core open source?
The library is source-published for review; there is no public repository yet. 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.
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. Start at the Trust Center.