xGhost: Ephemeral Algorithm Protection
Your algorithm runs everywhere. Exists nowhere. XorIDA splits your code into shares — customers execute it but can never steal it. Per-call reconstruct and purge gives ~50µs exposure. 30-second xLink heartbeat authorization. You can't steal a ghost.
Tier 1 (Basic): XorIDA code splitting, 30-second heartbeat authorization, per-call reconstruct/execute/purge with tamper-evident HMAC audit chain.
Tier 2 (Secure): xPass session binding — ghost execution bound to active M2M connection. Heartbeat + connection expiry checks. Session-gated purge.
Tier 3 (Zero): xCompute MPC execution — algorithm never reconstructs on customer's machine. Each party executes on their XorIDA share. Results combined via MPC without plaintext exposure.
Enterprise toolkit shipped:
@private.me/xghost-cli — reference heartbeat server, 3-role RBAC, Docker deployment, CLI commands (build/verify/inspect/serve), end-to-end example. 67 enterprise tests. Part of the Enterprise CLI Suite — 21 self-hosted servers, 1,924 enterprise tests, Docker-ready, air-gapped capable.
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. License servers can be spoofed. Code signing proves origin but doesn't prevent copying. None of these provide cryptographic guarantees.
The Old Way
The PRIVATE.ME Solution
xGhost splits your compiled algorithm into XorIDA shares at build time. The customer installs Share 1 — which is cryptographic noise. Share 2 stays on your server. At runtime, per-call reconstruction assembles the code in memory for ~50 microseconds, executes it, and purges it. The algorithm ghosts in and out of existence.
Share 1 alone reveals zero information about your algorithm. Not obfuscated code — actual noise. Information-theoretically. A customer who copies their node_modules/ directory copies noise.
The 30-second xLink heartbeat ensures continuous authorization. Every 30 seconds, the SDK confirms the customer's DID is valid and their subscription is active. No payment → no Share 2 → no code → nothing runs.
The New Way
Three Tiers
xGhost offers three protection levels. Each uses our own cryptographic infrastructure — XorIDA, xLink, xPass, and xCompute — composed to match the threat model.
| Tier | How It Works | Code Exposure | Bypass Window |
|---|---|---|---|
| Basic | XorIDA-split code + per-call reconstruct/purge + 30s xLink heartbeat | ~50µs in memory per call | 30 seconds |
| Secure | Basic + xPass MPC session binding per session | ~50µs in memory, session-bound | 30 seconds |
| Zero | xCompute MPC execution — algorithm never leaves the server | None — never on customer machine | None |
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.
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.
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.
How It Works
The xGhost protection stack combines four PRIVATE.ME ACIs. Each layer adds defense. Together, they create cryptographic enforcement that cannot be bypassed by code theft.
Per-Call Execution Flow (xGhost Basic)
// 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.
Use Cases
Ship ML models to edge devices without exposing weights. xGhost Zero runs inference via MPC — the model never leaves your server, customers get predictions only.
Model SecurityDeploy proprietary trading strategies to on-prem customer infrastructure. xGhost Basic gives native-speed execution with ~50µs exposure. The algorithm stays yours.
Proprietary IPFDA-approved diagnostic algorithms run at the hospital but can't be copied. xGhost Secure binds execution to MPC sessions — the algorithm is licensed, not sold.
FDA / HIPAAShip enterprise software on-prem without losing control. Customers get results, not source code. Subscription lapse = code stops within 30 seconds.
License EnforcementGame logic runs ghosted — cheat developers can't extract and modify the algorithm. 30-second enforcement window vs. weeks for traditional DRM.
Tamper ResistanceDistribute SDKs as XorIDA shares. Customers install noise. Runtime reconstruction requires active subscription. No obfuscation needed — the protection is cryptographic.
Anti-PiracyIntegration
import { ghostBuild } from '@private.me/xghost'; // Your algorithm source code const source = new TextEncoder().encode(algorithmSource); // Split into XorIDA shares const result = await ghostBuild({ source, exports: ['matchClaims', 'scoreRisk'], heartbeatIntervalMs: 30_000, }); // result.customerShare → ship to npm (cryptographic noise) // result.vendorShare → keep on your server // result.manifest → ship alongside customerShare
import { createGhost } from '@private.me/xghost'; // Initialize with customer share + heartbeat server const ghostResult = await createGhost({ customerShare, // from npm install manifest, // from npm install server: heartbeatClient, // HeartbeatServer implementation did: 'did:key:z6Mk...', // customer's DID identity }); if (!ghostResult.ok) throw ghostResult.error; const ghost = ghostResult.value; // Call the ghosted function — per-call reconstruct + purge const result = await ghost.call('matchClaims', claimsData); // Algorithm existed in memory for ~50µs, then purged // Audit log: ghost.getAuditLog() → tamper-evident HMAC chain
Deployment Models
xGhost ships three deployment models. Same technology, different trust boundaries. Choose based on where the algorithm executes and who controls the infrastructure.
How Each Model Maps to Tiers
| Deployment | Basic | Secure | Zero |
|---|---|---|---|
| xGhost Cloud | API | API + MPC | API + xCompute |
| xGhost Edge | SDK + Heartbeat | SDK + xPass | — |
| xGhost Enterprise | Self-hosted | Self-hosted | Self-hosted |
Enhanced Identity with Xid
xGhost can optionally integrate with Xid to enable unlinkable algorithm execution — verifiable within each runtime context, but uncorrelatable across invocations, tenants, or time.
Three Identity Modes
How Ephemeral Execution Identity Works
// Initialize xGhost with Xid integration import { createGhostRuntime } from '@private.me/xghost-cli'; import { XidClient } from '@private.me/xid'; const xid = new XidClient({ mode: 'ephemeral' }); const runtime = createGhostRuntime({ identityProvider: xid }); // Each invocation derives unlinkable DID automatically const result = await runtime.execute('tradingAlgo', { symbol: 'AAPL' }); → [xGhost] Deriving ephemeral DID from master seed... → [xGhost] DID: did:key:z6MkD... (unique to this execution + tenant + epoch) → [xGhost] Reconstructed code with ephemeral identity (~50µs) → [xGhost] Executed algorithm, purged code (<1ms exposure) // Execution is audited with unlinkable DID // Verification works within tenant, but cross-tenant correlation fails
See the Xid white paper for details on ephemeral identity primitives and K-of-N convergence.
Market Positioning
| Industry | Use Case | Compliance Driver |
|---|---|---|
| FinTech | Trading algorithm protection with unlinkable execution logs | SEC 17a-4, FINRA 4511, SOX |
| Software Vendors (Anti-Piracy) | Ship protected algorithms to enterprise customers—code exists as noise until licensed runtime reconstructs. Unlinkable tenant execution prevents correlation across deployments. Piracy-proof: cloning the binary yields zero information (IT-secure). | IP protection, revenue assurance |
| Gaming | Anti-cheat algorithm protection with uncorrelatable invocations | IP protection, competitive integrity |
| Defense | Classified algorithm execution with IAL3 operator identity | FISMA, DoD IL5/6, CMMC Level 3 |
Key Benefits
- Cross-tenant unlinkability — Can't track executors across customers
- Per-invocation derivation — Same executor has different DIDs per call
- Epoch rotation — DIDs automatically rotate daily/weekly/monthly
- Split-protected derivation — Master seed is XorIDA-split, never reconstructed
- IP protection — Execution identity bound to algorithm without exposing plaintext
- Audit without surveillance — Verifiable logs without cross-context correlation
Enterprise Toolkit
xGhost Enterprise ships as a complete self-hosted package. @private.me/xghost-cli provides the CLI, reference heartbeat server, RBAC, Docker deployment, and end-to-end tooling — everything needed to protect your first algorithm in minutes.
CLI Commands
# Split your algorithm into XorIDA shares xghost build --source algo.js --exports "score,classify" --output ./artifacts/ → customer-share.json, vendor-share.json, manifest.json # Start the reference heartbeat server xghost serve → HTTP server on :3100 with RBAC + JSONL stores # Verify an exported purge audit log xghost verify --audit-log ./audit.json → Replays HMAC chain, reports integrity # Inspect a manifest xghost inspect --manifest ./manifest.json → Magic, version, threshold, exports, heartbeat interval
Reference Heartbeat Server
Built on Node.js built-in http module — zero external dependencies. Seven endpoints: heartbeat, algorithm upload, license CRUD, audit log, health check. Vendor shares encrypted at rest with AES-256-GCM (key from env var or KMS).
3-Role RBAC
| Role | Permissions |
|---|---|
| Admin | Create/revoke licenses, rotate shares, manage API keys, read audit logs, upload algorithms |
| Operator | Upload algorithm artifacts, read license status |
| Auditor | Read heartbeat logs, read license metadata |
Docker Deployment
Multi-stage Alpine build. Non-root user. Read-only filesystem. Health checks. docker compose up and your heartbeat server is running. Air-gapped deployment supported via docker save/load.
Security Properties
| Property | Mechanism | Guarantee |
|---|---|---|
| Code Confidentiality | XorIDA 2-of-2 splitting | Share 1 alone = zero information (information-theoretic) |
| Authorization | xLink 30s heartbeat | DID-authenticated, timestamp-bound, nonce replay prevention |
| Session Binding | xPass MPC (Secure tier) | Server participation required per session |
| Algorithm Secrecy | xCompute MPC (Zero tier) | Algorithm never exists on customer machine |
| Integrity | HMAC-SHA256 per share | Tampered shares rejected before reconstruction |
| Execution Proof | xProve audit trail | Cryptographic proof of correct execution |
Competitive Comparison
| Approach | Bypass Window | Cryptographic? | Code Readable? |
|---|---|---|---|
| Obfuscation | Permanent access | No | Harder but yes |
| License Key | Permanent once cracked | No | Fully readable |
| Hardware Dongle | Until cloned | No | Fully readable |
| Server-Only (SaaS) | None | N/A | Not shipped |
| xGhost Basic | ~50µs per call | Yes (XorIDA) | Noise on disk |
| xGhost Secure | ~50µs, session-bound | Yes (XorIDA + MPC) | Noise on disk |
| xGhost Zero | None | Yes (xCompute MPC) | Never shipped |
Benchmarks
Performance characteristics measured on Node.js 22, Apple M2. The complete ghost lifecycle — build, create, call, purge — completes in under 2 milliseconds.
| Operation | Time | Notes |
|---|---|---|
| ghostBuild() | <0.5ms | Compile algorithm into executable ghost |
| createGhost() | <0.3ms | XorIDA split algorithm into shares |
| ghost.call() | <0.5ms | Reconstruct → execute → purge |
| HMAC integrity check | <0.1ms | Verify share integrity before reconstruction |
| Heartbeat check | <0.1ms | Enterprise: license validation per call |
| Algorithm purge | <1µs | Zero-fill reconstructed algorithm from memory |
| Full pipeline | <2ms | Build → create → call → verify → purge |
Algorithm Protection Comparison
| Property | Obfuscation | Intel SGX | Homomorphic Encryption | xGhost |
|---|---|---|---|---|
| Algorithm exposure | Reversible with effort | Protected in enclave | Never exposed | ~1.5ms window only |
| Execution overhead | ~1.2x | ~1.5x | ~10,000x | <2ms total |
| Reverse engineering | Possible (Ghidra, IDA) | Side-channel attacks | Infeasible | No persistent artifact |
| Quantum resistance | No | Hardware-dependent | Lattice-based | IT-secure (XorIDA) |
| Hardware required | No | Yes (SGX CPU) | No | No |
Ship Proofs, Not Source
xGhost generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.
- Tier 1 HMAC (~0.7KB)
- Tier 2 Commit-Reveal (~0.5KB)
- Tier 3 IT-MAC (~0.3KB)
- Tier 4 KKW ZK (~0.4KB)
Use Cases
Honest Limitations
Five known limitations documented transparently. xGhost provides practical algorithm protection with explicit constraints.
| Limitation | Impact | Mitigation |
|---|---|---|
| Algorithm must fit in memory | The complete algorithm is reconstructed in memory for execution. Algorithms larger than available RAM cannot be processed. | Most proprietary algorithms are <1 MB. For larger models, chunk into independent components and ghost each separately. |
| Execution window exposure ~1.5ms | During the ghost.call() execution window (~1.5ms), the reconstructed algorithm exists in process memory. A sufficiently privileged attacker with memory access could extract it. | The 1.5ms window is orders of magnitude shorter than any traditional execution model. TEE isolation (SGX/TrustZone) eliminates even this window. Automatic purge ensures no persistent artifact. |
| No partial execution | The algorithm executes atomically — all or nothing. Streaming or progressive execution is not supported. | Atomic execution prevents partial algorithm extraction. For streaming use cases, split the algorithm into stages and ghost each stage independently. |
| Heartbeat dependency (enterprise) | Enterprise ghosts require periodic heartbeat validation against the license server. Network interruptions block execution. | Heartbeat cache with configurable TTL (default 5 minutes) allows continued execution during brief network outages. Offline mode available for air-gapped deployments. |
| Single-threaded execution | Ghost execution runs in a single thread. Algorithms requiring parallel computation do not benefit from multi-core CPUs. | The execution window is <1.5ms — parallelism would not provide meaningful speedup at this scale. For compute-heavy algorithms, use xCompute MPC across distributed nodes. |
Verifiable Algorithm Protection
Every ghosted execution produces a verifiable audit trail via xProve. HMAC-chained integrity proofs confirm that the algorithm was reconstructed correctly, executed faithfully, and purged completely.
Read the xProve white paper →
Ready to deploy xGhost?
Talk to Sol, our AI platform engineer, or book a live demo with our team.