xGhost: Ephemeral Algorithm Protection

Executive Summary

xGhost protects your proprietary algorithms from theft when deployed to customer infrastructure. The algorithm ships as cryptographic noise. At runtime, it ghosts in and out of existence — reconstructing only for the microseconds needed to execute, then purging immediately.

When you ship code to customers, you lose control of it. xGhost changes this: your algorithm is XorIDA-split into 2-of-2 shares at build time. Share 1 ships in the npm package — it is indistinguishable from random noise. Share 2 stays on your server. At each function call, the SDK fetches Share 2 via xLink (encrypted, DID-authenticated, 30s timestamp-bound), reconstructs the algorithm in memory for ~50µs, executes it, and purges the reconstructed code.

A customer who copies their node_modules/ directory copies noise. An attacker who dumps process memory during execution has a ~50-microsecond window. The 30-second heartbeat ensures continuous authorization — if a subscription lapses, the code stops running within 30 seconds.

Three tiers available: Basic (heartbeat + reconstruct/purge), Secure (+ xPass session binding), Zero (xCompute MPC execution — algorithm never leaves your server). All three tiers fully implemented. 112 tests passing. Enterprise toolkit shipped.

Developer Experience

xGhost provides real-time progress tracking and 28+ structured error codes to help developers build reliable algorithm protection systems.

Progress Callbacks

Ghost operations support onProgress callbacks for tracking authorization checks, share fetching, reconstruction, execution, and purging.

const result = await ghost.execute({
  input: userData,
  onProgress: async (event) => {
    switch (event.stage) {
      case 'authorizing':
        console.log('Checking heartbeat...');
        break;
      case 'fetching':
        console.log('Retrieving Share 2...');
        break;
      case 'reconstructing':
        console.log('Reconstructing algorithm...');
        break;
      case 'executing':
        console.log('Running protected function...');
        break;
      case 'purging':
        console.log('Purging reconstructed code...');
        break;
      case 'complete':
        console.log('Execution complete');
        break;
    }
  }
});

Structured Error Handling

xGhost uses a Result<T, E> pattern with detailed error structures. Every error includes a machine-readable code, human-readable message, actionable hint, and documentation URL.

interface ErrorDetail {
  code: string;         // e.g., 'HEARTBEAT_EXPIRED'
  message: string;      // Human-readable description
  hint?: string;        // Actionable suggestion
  field?: string;       // Field that caused the error
  docs?: string;        // Documentation URL
}

Error Categories

xGhost organizes 28+ error codes across 6 categories:

Full error taxonomy documented in the Advanced Reference section below.

The Problem

When you ship code to customers, you lose control of it. Obfuscation is reversible. DRM is crackable. License keys are shareable. JavaScript is readable. Your algorithm — your core IP — becomes their property the moment it leaves your server.

Software vendors face an impossible choice: keep your algorithm on your server (adding latency, requiring connectivity, creating a single point of failure) or ship it to customers (and accept that it will be reverse-engineered, copied, and redistributed).

Current protection approaches all fail at the architectural level:

• Obfuscation makes code harder to read but doesn't prevent execution analysis
• Hardware dongles add friction and are expensive to deploy
• License servers can be spoofed or bypassed
• Code signing proves origin but doesn't prevent copying
• WebAssembly is still extractable and reversible

None of these provide cryptographic guarantees. They make theft harder. xGhost makes it impossible.

Real-World Use Cases

Solution Architecture

xGhost combines four PRIVATE.ME building blocks — XorIDA, xLink, xPass, and xCompute — into a three-tier algorithm protection system. Each tier adds defense. Together, they provide cryptographic enforcement that cannot be bypassed by code theft.

Three Tiers

xGhost offers three protection levels. Each uses PRIVATE.ME's cryptographic infrastructure composed to match the threat model.

Tier 1: xGhost Basic

Your algorithm is XorIDA-split at build time into 2-of-2 shares. Share 1 ships in the npm package — it's cryptographic noise. At each function call, the SDK fetches Share 2 from your server via xLink (encrypted, DID-authenticated, 30s timestamp-bound). XorIDA reconstructs the code in memory, executes the function, and immediately purges the reconstructed code. The entire cycle takes ~50 microseconds.

The 30-second xLink heartbeat ensures continuous authorization. Every 30 seconds (configurable), the SDK confirms the customer's DID is valid and their subscription is active. No payment → no Share 2 → no code → nothing runs.

Tier 2: xGhost Secure

Adds xPass MPC session binding. The server participates in a 3-party MPC session establishment — even if an attacker intercepts Share 2, it's bound to a session key that requires the server's cooperation. Session keys expire with each 30-second heartbeat cycle.

xPass also enforces per-session billing. Each ghost execution counts as one M2M connection. The billable unit is (customer_did, server_did, scope). Sessions automatically close after heartbeat expiry.

Tier 3: xGhost Zero

The algorithm never exists on the customer's machine in any form. Instead, the customer provides their data as shares, and xCompute performs the computation via MPC. The customer gets results; the server keeps the algorithm.

For XorIDA-based operations (all XOR gates), MPC communication overhead is zero — Class 1 gates are free by GF(2) linearity. This means XorIDA-based algorithms run under xGhost Zero with near-zero latency penalty. No other cryptographic primitive has this property.

Per-Call Execution Lifecycle

Every protected function call goes through a six-stage lifecycle: authorize, fetch, reconstruct, execute, purge, return. The entire cycle completes in under 2 milliseconds.

// Customer calls the protected function:
const result = await ghostedAlgorithm(inputData);

// Under the hood (SDK handles automatically):
// t=0.000ms  Check 30s heartbeat cache (is DID still authorized?)
// t=0.001ms  Pull Share 2 from local cache (pre-fetched via xLink)
// t=0.035ms  XorIDA reconstruct (Share 1 + Share 2 → code)
// t=0.050ms  Execute function with input data
// t=0.086ms  Purge reconstructed code from memory
// t=0.087ms  Return result to customer
//
// Total: ~87µs. Code existed for ~50µs.

HMAC Audit Chain

Every reconstruction is logged in a tamper-evident HMAC chain. Each execution generates:

• Timestamp — when the function was called
• Customer DID — who ran it
• Input hash — SHA-256 of the input data
• Output hash — SHA-256 of the result
• HMAC — chained from previous execution

The chain is verifiable via xProve. If an attacker modifies Share 1 or Share 2, the HMAC breaks. If they replay an old Share 2, the timestamp is stale. If they skip purging, the next call's HMAC will fail.

Four-Layer Protection Stack

Each layer addresses a different attack surface. Together, they create defense in depth.

Layer 1: XorIDA Code Splitting

At build time, the compiled algorithm is XorIDA-split into 2-of-2 shares. Share 1 is cryptographic noise — information-theoretically indistinguishable from random. No computation (classical or quantum) can extract information about the algorithm from Share 1 alone. This is not obfuscation. It's a mathematical proof.

Layer 2: xLink 30s Heartbeat

Every 30 seconds, the SDK confirms the customer's DID is authorized via xLink (DID-authenticated encrypted channel). The heartbeat request includes:

• Customer DID (Ed25519-signed)
• Timestamp (30s window)
• Nonce (replay prevention)
• Subscription status (active/lapsed)

If the heartbeat fails, the next reconstruction fails. Code execution stops within one heartbeat cycle.

Layer 3: xPass Session Binding (Tier 2)

xPass binds Share 2 delivery to an active MPC session. The server participates in a 3-party key establishment. Even if an attacker intercepts Share 2, they cannot reconstruct without the server's cooperation. Session keys rotate with every heartbeat.

Layer 4: xCompute MPC Execution (Tier 3)

The algorithm never reconstructs. The customer provides data as shares. xCompute performs computation via MPC. The customer gets results. The server keeps the algorithm. For XorIDA operations, MPC overhead is zero.

Complete Flow

From build-time splitting to runtime execution, here's how xGhost protects your algorithm end-to-end.

Build Time

import { splitAlgorithm } from '@private.me/xghost';

// Your proprietary function
function proprietaryAlgorithm(input: Data): Result {
  // ... your secret logic ...
  return result;
}

// Split into 2-of-2 shares
const { share1, share2, metadata } = await splitAlgorithm(proprietaryAlgorithm);

// share1 → ships in npm package (cryptographic noise)
// share2 → stays on your server
// metadata → reconstruction parameters

Runtime (Customer Side)

import { GhostClient } from 'your-package';

// SDK auto-loads Share 1 from node_modules/
const ghost = new GhostClient({
  serverUrl: 'https://api.yourcompany.com',
  customerDid: 'did:key:z6Mk...',
  heartbeatInterval: 30000  // 30 seconds
});

// First heartbeat → fetches Share 2 → caches locally
await ghost.initialize();

// Execute protected function
const result = await ghost.execute(inputData);
// → Reconstructs from Share 1 + Share 2
// → Runs for ~50µs
// → Purges immediately
// → Returns result

Runtime (Server Side)

import { GhostServer } from '@private.me/xghost-cli';

const server = new GhostServer({
  port: 3200,
  authorize: async (did: string) => {
    // Check subscription status in your database
    const customer = await db.customers.findOne({ did });
    return customer?.subscriptionActive === true;
  }
});

// Heartbeat endpoint: POST /ghost/heartbeat
// Returns Share 2 if authorized, 403 if not
server.start();

Integration Patterns

Three integration patterns for different deployment models.

Security Properties

What xGhost protects against, what it doesn't, and why.

Threat Model

Attacker capabilities:

• Full access to Share 1 (shipped in npm package)
• Full access to customer's process memory (debug, dump, inspect)
• Full access to customer's filesystem and network traffic
• Can modify Share 1 (tampering)
• Can attempt to replay old Share 2 responses
• Can attempt to bypass heartbeat checks

Attacker goals:

• Extract the algorithm to run independently
• Redistribute the algorithm to non-paying customers
• Continue running after subscription lapses
• Reverse-engineer the algorithm logic

Security Guarantees

What xGhost Does NOT Protect

xGhost protects the algorithm, not the results. If the algorithm produces predictable outputs, an attacker can:

• Collect input/output pairs and train a surrogate model
• Infer the algorithm's behavior from usage patterns
• Cache results and serve them without running your code

If the algorithm is simple enough to infer from I/O pairs, xGhost cannot help. Use xGhost for algorithms with:

• High complexity (not easily reverse-engineerable from examples)
• Proprietary training data or weights (ML models)
• Trade secrets embedded in the logic (financial strategies)
• Unique value that justifies the overhead

Benchmarks

Performance measurements for all three tiers. All benchmarks run on Node.js v20 (M1 Mac, 16GB RAM).

Tier 1: xGhost Basic

Tier 2: xGhost Secure

Tier 3: xGhost Zero

Honest Limitations

What xGhost cannot do, and when you should not use it.

1. Output Inference Attacks

xGhost protects the algorithm, not the results. If your algorithm is simple enough to infer from input/output pairs, an attacker can train a surrogate model. xGhost does not prevent this.

When this matters: Deterministic functions with small output spaces (e.g., "is this prime?" can be inferred after enough queries).

Mitigation: Use Tier 3 (xCompute MPC) and add noise to outputs, or use xGhost only for algorithms too complex to infer.

2. Memory Dump Attacks During Execution

Tier 1 and Tier 2 reconstruct the algorithm in memory for ~50µs. An attacker with root access who dumps process memory at precisely the right moment can extract it.

When this matters: Sophisticated attackers with debugger access and timing control.

Mitigation: Use Tier 3 (algorithm never reconstructs) or run in a secure enclave (SGX, TrustZone).

3. Server Availability Dependency

xGhost requires periodic heartbeat connectivity to your server. If your server is down or unreachable, the customer's code stops within one heartbeat cycle (default 30 seconds).

When this matters: Mission-critical systems that cannot tolerate server downtime.

Mitigation: Deploy heartbeat servers in multiple regions with failover, or increase heartbeat interval to reduce sensitivity.

4. Not Suitable for Simple Algorithms

If your algorithm is trivial (e.g., "multiply by 2"), the overhead of xGhost outweighs any protection benefit. Use xGhost for:

• ML model weights or trained parameters
• Proprietary trading strategies
• FDA-approved medical algorithms
• Complex financial risk models
• Anything worth protecting with cryptography

5. Build-Time Complexity

Splitting an algorithm at build time requires compiling to a serializable format (e.g., WebAssembly, bytecode). Dynamic code (e.g., eval(), runtime code generation) cannot be split.

When this matters: Algorithms that generate code at runtime.

Mitigation: Refactor to use static control flow, or split only the critical sub-algorithms.

Error Hierarchy

Typed error classes for structured error handling. Supplementary to the Result<T,E> string code pattern.

XGhostError                   // Base class (code, subCode, docUrl)
  ├── XGhostAuthError         // Heartbeat, DID authorization
  ├── XGhostReconstructError  // XorIDA reconstruction, HMAC
  ├── XGhostExecutionError    // Protected function execution
  ├── XGhostSessionError      // xPass session binding (Tier 2)
  ├── XGhostMPCError          // xCompute MPC execution (Tier 3)
  └── XGhostConfigError       // SDK initialization, config

All error classes extend XGhostError and include:

• code: machine-readable error code (e.g., HEARTBEAT_EXPIRED)
• subCode: optional sub-classification
• docUrl: link to error documentation
• context: additional debugging data (did, timestamp, etc.)

Full ACI Surface

Complete SDK API for all three tiers.

Core Functions

Server Functions (xghost-cli)

Error Taxonomy

All 28+ error codes with descriptions and hints.

Full error reference: docs/errors/xghost

Codebase Stats

Package structure and test coverage.

Package Structure

packages/xghost/
├── src/
│   ├── index.ts            // Public API exports
│   ├── split.ts            // Build-time algorithm splitting
│   ├── client.ts           // Runtime client SDK
│   ├── lifecycle.ts        // Reconstruct/execute/purge
│   ├── heartbeat.ts        // Authorization checks
│   ├── session.ts          // Tier 2: xPass binding
│   ├── mpc.ts              // Tier 3: xCompute execution
│   ├── audit.ts            // HMAC audit chain
│   ├── errors.ts           // Error classes + ERROR_DETAILS
│   └── types.ts            // TypeScript interfaces
└── __tests__/
    ├── split.test.ts        // Build-time splitting
    ├── lifecycle.test.ts    // Execution lifecycle
    ├── heartbeat.test.ts    // Authorization
    ├── session.test.ts      // Tier 2 session binding
    ├── mpc.test.ts          // Tier 3 MPC execution
    ├── audit.test.ts        // HMAC chain
    ├── errors.test.ts       // Error handling
    ├── integration.test.ts  // End-to-end flows
    └── abuse.test.ts        // Attack scenarios

Enterprise CLI

@private.me/xghost-cli ships with the enterprise toolkit: reference heartbeat server, 3-role RBAC (admin/operator/auditor), Docker deployment, CLI commands (build/verify/inspect/serve), end-to-end examples. 67 enterprise tests. Part of the Enterprise CLI Suite — 21 self-hosted servers, 1,924+ tests, Docker-ready, air-gapped capable.