INVITE ONLY
OBSERVATORY

Solutions · 05

Build on the core we ship ourselves.

One Rust library beneath every platform — ML-KEM-1024, ML-DSA-87, X25519, ChaCha20-Poly1305 behind a single FFI surface. What we run is what you read.

CRYPTO-CORE Rust · one FFI surface

Read the handshake exactly as it ships.

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, salted by the ciphertexts and bound to the public material. Non-contributory X25519 points are rejected before any key leaves the function.

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

Distributed binaries are verifiable against the source through reproducible builds. A build-attestation manifest is published (ML-DSA-87, ctx QERYX-attest-v1); the update-authenticity trust-root registry is not yet claimed — the gap is stated because you would find it anyway.

Run the relay yourself

The backend deploys from a single compose file, and the carrier model means your instance holds ciphertext and opaque routing identifiers — nothing readable, nothing to leak. Start with the self-hosting guide.

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?

The repositories, licenses, and contribution paths live on the open-source page — including what is open today and what opens on the published schedule, stated exactly.

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.