Solutions · 05
Build on the core beneath QERYX.
One Rust library beneath every platform — ML-KEM-1024, ML-DSA-87, X25519, ChaCha20-Poly1305 behind a single FFI surface. What we build is what you read.
01 / THE HANDSHAKE — AS WRITTEN
Read the handshake exactly as it is written.
pub fn hybrid_encapsulate(
public_key: &HybridPublicKey,
) -> Result<(HybridCiphertext, HybridSharedSecret), CryptoError> {
// Generate ephemeral X25519 keypair
let x25519_ephemeral_secret = x25519_dalek::EphemeralSecret::random_from_rng(OsRng);
let x25519_ephemeral_public = X25519PublicKey::from(&x25519_ephemeral_secret);
// Compute X25519 shared secret
let x25519_shared: SharedSecret = x25519_ephemeral_secret.diffie_hellman(&public_key.x25519);
reject_non_contributory_x25519(&x25519_shared)?;
// Encapsulate to ML-KEM public key
let (kyber_ciphertext, kyber_shared) = public_key.kyber.encapsulate()?;
// Construct combiner inputs
let ciphertext = HybridCiphertext {
x25519_ephemeral: x25519_ephemeral_public,
kyber_ciphertext,
};
// Combine shared secrets using HKDF-SHA512
let shared_secret = combine_shared_secrets(
x25519_shared.as_bytes(),
kyber_shared.as_bytes(),
&ciphertext,
public_key,
)?;
Ok((ciphertext, shared_secret))
}
The NIST SP 800-227 §6.2 concatenation combiner: HKDF-SHA-512 over the ML-KEM-1024 and X25519 shared secrets, with a fixed-literal salt and the recipient's X25519 key and the ML-KEM ciphertext bound into info. Non-contributory X25519 points are rejected before any key leaves the function on the library handshake; the messenger's own exchange adopts the same screen in the next revision.
Link one core on every platform
The iOS app, the Android app, and the backend all call the same Rust library through one FFI surface. There is no per-platform crypto reimplementation to drift, and the module forbids unsafe code on the shared-secret path.
Verify first, then trust
The path from a released binary back to source will run through reproducible builds. The build-attestation manifest format is in the tree (ML-DSA-87, ctx QERYX-attest-v1) and signs build outputs; the first public manifest arrives with v1.0.0, and the update-authenticity trust-root registry is not yet claimed — the gaps are stated because you would find them anyway.
Plan to run the relay yourself
The backend will deploy from a single compose file, and the carrier model means your instance will hold ciphertext and opaque routing identifiers — nothing readable, nothing to leak. The kit is not public yet; the self-hosting docs say where the public path stands.
05 / THREE DEPTHS
Pick your depth and go down it.
06 / THE HARD QUESTIONS
Ask the three that decide it.
Which primitives does crypto-core expose?
ML-KEM-1024 (FIPS 203), ML-DSA-87 (FIPS 204), X25519, and ChaCha20-Poly1305 (RFC 8439), combined under HKDF-SHA-512 — the same surface every QERYX platform calls. The crypto-core docs map the API.
Where is the source and the license?
What is public today, the licenses off the tree, and the review path are set out on the open-source page — stated exactly, including what is not yet open.
Is the WASM demo crypto on this site real?
Yes — the site's interactive demos run the real primitives in your browser on authored demo content; nothing poses as crypto that is not. Where a demo uses an independent implementation of the same primitive, the label on the island says so.
Read the core. Then hold us to it.
The library is the claim — everything else is commentary.