Platform
Solutions
Industries
Resources
Company
Request a briefing
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). 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 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) — visualized 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.

Reconstruction happens on your device

The read path is the write path in reverse, and it runs client-side. Fetch the shard manifest, pull shards in parallel, Reed-Solomon decode, then AES-GCM decrypt with a key the server has never held unwrapped. The server never assembles a readable copy — there is no API path that returns plaintext, because on that side of the boundary there is no plaintext to return.

Memory-flat, whatever the size. Downloads never allocate a full-file buffer at any layer, on the server or the client. A 50 GB file streams exactly as a 50 MB one does, and a cancelled download stops pulling shards immediately rather than finishing quietly in the background.

In the browser, not just the desktop. The web client runs all four steps itself — WebCrypto for AES-GCM, Reed-Solomon decoding in JavaScript, hardware-accelerated where the runtime allows. Nothing about the guarantee depends on installing software.

Across battery cycles. Mobile clients persist in-flight reconstruction state locally, so an OS-killed app or a backgrounded session resumes on next launch instead of starting over.

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

    Finalizes 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