Offchain Decryption

Encifher combines on‑chain programs with an off‑chain Co‑Processor to enable computations over encrypted state. Smart contracts work with 16‑byte handles (symbolic references) instead of raw ciphertexts, while the Co‑Processor performs decrypt → compute → encrypt inside a trusted environment and coordinates storage and commitments across services.

• On‑chain: programs operate over handles rather than plaintext or full ciphertexts.
• Off‑chain Processor: orchestrates decrypt → compute → encrypt and pushes merkle‑committed results.
• Indexer: caches handle → ciphertext mappings and returns ciphertexts (plus proofs) when requested.
• Submitter: accumulates batch roots and submits a compact, TEE‑signed commitment on‑chain.
• Offchain decryption: a read path where the Processor validates a signed time‑bounded session, decrypts ciphertexts, and re‑encrypts results to a client‑provided ephemeral key for local readout.

Overview

Offchain decryption lets clients privately read values for encrypted handles. The SDK opens a short‑lived session, the processor validates it, batch‑decrypts ciphertexts, and re‑encrypts each plaintext to the client's ephemeral key.

• Purpose: view plaintext values for encrypted handles without exposing them to the network.
• Who calls it: the SDK prepares a signed, time‑bounded request and calls the Processor.
• What user need:
  • Ephemeral ECIES‑compatible keypair (SDK‑generated) for receiving data.
  • Wallet (Ed25519) signature over a deterministic payload hash.
  • Session timestamps (in seconds, not milliseconds) constrained to ≤ 3600 seconds duration.

Key Concepts

• Ephemeral key (ECIES): keypair generated per session and stored in sessionStorage (browser) or memory (Node.js). The Processor re‑encrypts each plaintext to this public key using ECIES; only the requester can decrypt locally with the matching private key.
• Session payload: deterministic JSON payload containing ephemeral_pub_key, decryption_type, start_time_stamp, end_time_stamp, signed with the wallet (Ed25519). Must be valid at request time and within the configured ≤3600s window.
• Handles: 16‑byte references (type: u128) to encrypted values. Requests provide one or more handles; the Processor fetches corresponding ciphertexts from the Indexer (production) or a local dev DB (debug) before decryption.
• Threshold decrypt → ECIES re‑encrypt: ciphertexts are batch‑decrypted once (threshold KMS), then each plaintext is individually re‑encrypted to the requester's ephemeral public key.
• Actors: SDK (prepare session and call API), Processor (validate → decrypt → re‑encrypt), Indexer (ciphertext retrieval), KMS/TEE (batch threshold decryption within a trusted boundary).

Diagram

Flow Walkthrough

1. SDK prepares session: Generates an ephemeral ECIES‑compatible keypair (stored in sessionStorage for browsers), constructs payload with timestamps in seconds, creates SHA-256 hash of camelCase JSON representation, and signs with the user's Ed25519 wallet key (external to SDK).

2. SDK sends request: POSTs to /v1/re-encrypt with snake_case field names, signature, and list of handle strings.

3. Processor validates: Verifies Ed25519 signature against reconstructed camelCase JSON payload hash, checks time window constraints (current time within [start, end] and duration ≤ 3600s). Then fetches ciphertexts from the Indexer (production) or from local Sled dev_db (debug mode).

4. Processor decrypts and re-encrypts: Performs a single batch threshold decryption for all ciphertexts in one KMS call (O(1) threshold sessions instead of O(n)), then iterates through plaintexts and individually re-encrypts each one to the client's ephemeral public key using ECIES.

5. Processor returns results: Sends JSON response with results[] array (each entry contains hex-encoded ECIES ciphertext and status), along with user_pk, ephemeral_pub_key, and session_info metadata. The SDK decrypts each result locally using the ephemeral private key with ECIES decryption.