QERYX COMING SOON
OBSERVATORY

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.

CRYPTO-CORE Rust · one FFI surface

Read the handshake exactly as it is written.

crypto-core/src/hybrid.rs — verbatim excerpt
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.

Pick your depth and go down it.

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.