Platform
Solutions
Industries
  • Pricing
    • Resources
    Company
    Request a briefing Sign in
    How it works

    From your file to your jurisdictions, in four steps.

    The encrypt-encode-scatter pipeline is the same whether you upload through the web app, an Outlook add-in, an S3-compatible client, or the Windows virtual drive. Here's exactly what happens.

    THE PIPELINE Four stages from device to scatter — reversed on read. 01 DEVICE Your file, framed ~5 MB frames. Memory-flat, streamable at any file size. LOCAL 02 ENCRYPT AES-256-GCM Per-file DEK, wrapped by AES-KW + ML-KEM-1024 (PQ). FIPS 197 + 203 03 ENCODE Reed-Solomon RS(5,2) Each frame → 7 shards. 5 data + 2 parity. Fewer than 5 reveal nothing. LOSE 2 OK 04 SCATTER Across 7 jurisdictions Allow-list enforced at upload. Async, idempotent, retryable. SOVEREIGN READ PATH · REVERSED Fetch 7 shards → any 5 reconstruct → client-side decrypt. Server never assembles plaintext. 4 STAGES 7 SHARDS / FRAME <4ms ENCRYPT + ENCAP Ø PLAINTEXT SERVER-SIDE
    The full pipeline at a glance — write top, read bottom, server never sees plaintext.
    1. STEP 01

      Encrypt on your device

      Your file is read frame-by-frame in ~5 MB chunks. Each frame is encrypted with AES-256-GCM using a per-file unique data-encryption key (DEK) and a deterministic IV bound to (file_id ‖ frame_index). Additional Authenticated Data binds ciphertext to file identity — shard substitution is detected at decrypt.

      The DEK is wrapped with AES Key Wrap (SP 800-38F). On the Sovereign tier, it is additionally wrapped with ML-KEM-1024 — hybrid post-quantum protection. The wrap key (UMK) is derived from your password via scrypt and never leaves your device in unwrapped form.

    2. STEP 02

      Erasure-encode into seven shards

      Each encrypted frame is RS(5,2)">Reed-Solomon RS(5,2) encoded into seven shards — five data shards and two parity shards. Any five are enough to fully reconstruct the frame. The shards carry per-shard SHA-256 hashes for downstream bit-rot detection.

    3. STEP 03

      Scatter across your providers

      Shards are distributed across seven different providers from your connexion set, subject to your jurisdictional policy (allow-list, block-list, strict-mode). Idempotent upload keys make scatter retryable without duplication. Async scatter returns the HTTP 202 the moment the bytes hit tmpfs staging — your client doesn't wait on provider-write latency.

    4. STEP 04

      Read by reversing

      When you request the file, the client fetches all seven shards in parallel. As soon as any five succeed, it Reed-Solomon-decodes locally, AES-GCM-decrypts frame-by-frame, and streams plaintext into the application. The server never assembles your file. The keys never leave your device. Memory cost is one frame.

    ONE FRAME, SEVEN SHARDS, SEVEN JURISDICTIONS The fan-out at the heart of Reed-Solomon RS(5,2) — visualised once. FRAME N ~5 MB PLAINTEXT AES-256-GCM CIPHERTEXT DEK-WRAPPED 9F2A 7B4C RS(5,2) ENCODE S1 DATA S2 DATA S3 DATA S4 DATA S5 DATA P1 PARITY P2 PARITY CA EU US UK AU NZ JP ANY 5 RECONSTRUCT · FEWER THAN 5 REVEAL NOTHING
    One frame, seven shards, seven jurisdictions — the fan-out made literal.
    What it means in practice

    Attack and compulsion, redrawn.

    Once you understand the pipeline, the security properties follow.

    THE ATTACK MATRIX Four adversary types. Four reasons the architecture holds. ADVERSARY 01 External attacker breaching one provider GETS 2 encrypted shards of 7. Even 5 would still be UMK-wrapped. INSUFFICIENT ADVERSARY 02 Court compelling one provider GETS Ciphertext shards. No plaintext. Compelling 5 requires 5 jurisdictions. CONTAINED ADVERSARY 03 Platform operator (SkyeConnex) HOLDS Metadata, audit logs, wrapped UMK. No capability to derive plaintext exists. ZERO-KNOWLEDGE ADVERSARY 04 Quantum adversary (harvest-now-decrypt-later) DEFEATS RSA, ECC. Not AES-256-GCM. Hybrid ML-KEM-1024 + AES-KW seals. QUANTUM-READY
    Four adversaries. Four reasons the architecture holds. Each insufficient on its own — the topology compounds the difficulty.

    An attacker breaching one provider

    Gets two encrypted shards of any file — not enough to reconstruct, and even if they had the other five, the AES-256-GCM key is wrapped by a UMK they don't hold. Two cryptographic walls before any plaintext is recoverable.

    A court compelling one provider

    Receives ciphertext shards. To compel decryption, the court must compel at least five different providers — in as many jurisdictions as the customer chose. In practice the request fails at the second jurisdiction, and even success yields ciphertext, not plaintext.

    The platform operator

    Holds metadata, audit logs, and the wrapped UMK. Cannot derive plaintext. Cannot be compelled to derive plaintext because the capability does not exist server-side.

    A future quantum adversary

    Defeats RSA, ECC. Does not defeat AES-256-GCM. The hybrid ML-KEM-1024 + AES-KW wrap means a quantum break alone is insufficient — the symmetric key remains protected.

    Reliability primitives

    Field-grade upload reliability.

    The five-endpoint chunked upload protocol — Init, Put, Status, Complete, Cancel — handles intermittent connectivity, OS-killed apps, dead batteries, and field-network conditions.

    1. INIT

      POST /api/upload/chunked/init

      Returns an upload_id and a server-determined 5 MB frame size. Frame size is non-negotiable because RS encoding has hard per-frame caps.

    2. PUT

      PUT /api/upload/chunked/<id>/<chunk_index>

      Each chunk, with an optional X-CR-Chunk-SHA256 header for per-chunk TCP-corruption detection at PUT time.

    3. STATUS

      GET /api/upload/chunked/<id>/status

      Returns the set of received chunk indices. A client resumes after any interruption by re-PUTting only the missing indices.

    4. COMPLETE

      POST /api/upload/chunked/<id>/complete

      Finalises the file: 200 when fully scattered, or 202 status="scattering" while async scatter is still distributing shards — clients poll Status until done.

    5. CANCEL

      POST /api/upload/chunked/<id>/cancel

      Releases the server-side staging directory and frees the session. No orphans.

    See the pipeline run live.

    Book a briefing. We'll upload a file in front of you and walk through every step from local encrypt to multi-provider scatter — with the SkyeMap showing exactly where each shard landed.

    Request a briefing → Architecture deep-dive