Unstealable Code: Algorithm Protection

Executive Summary

Unstealable Code makes algorithms mathematically non-functional without vendor authorization. Rather than protecting code that exists on the client, it implements a novel distribution model where code literally does not exist without vendor cooperation.

Traditional algorithm protection fails because if it exists, it can be copied. Obfuscation, DRM, license keys, and code signing all assume the algorithm is present on the client system. Attackers reverse engineer, memory dump, or simply share credentials.

Unstealable Code solves this by splitting algorithms via XorIDA threshold sharing at build time. Customers receive Share 1 (cryptographic noise), vendors hold Share 2. Reconstruction requires active session plus payment verification. Code exists only during execution — reconstructs in ~50µs, executes, purges in ~20µs. Total cycle under 2ms.

Zero-knowledge proofs (KKW protocol, ~50KB proofs at 128-bit security) allow auditors to verify correctness without accessing source code. Regulators can validate SEC compliance, FDA test coverage, or ITAR export controls — all without exposing trade secrets.

Three deployment tiers: Tier 1 (heartbeat authorization, 2-8 hour sessions), Tier 2 (billing enforcement via session binding), Tier 3 (MPC execution where code never reconstructs — executes on shares via garbled circuits).

Developer Experience

Integration is transparent to application logic. Protected algorithms export the same interface as unprotected code.

Build-Time Integration

Developers mark functions for protection via decorator or build configuration. The build pipeline automatically splits marked algorithms via XorIDA, generates zero-knowledge proofs, and packages Share 1 with manifests.

import { unstealable } from '@private.me/unstealable-code';

// Decorator marks function for threshold sharing
@unstealable({ tier: 2, scope: 'proprietary-algorithm' })
export async function tradingStrategy(marketData: MarketData): Promise<Trade[]> {
  // Proprietary logic here
  // This function will be XorIDA-split at build time
  return optimizePortfolio(marketData);
}

Runtime Behavior

From the application's perspective, protected functions work identically to regular functions. The SDK handles session establishment, heartbeat checks, share fetching, reconstruction, execution, and memory purge automatically.

// Application code doesn't change
const trades = await tradingStrategy(currentMarket);

// Under the hood (Tier 2):
// 1. Heartbeat check (~5ms, 30s TTL cache)
// 2. Fetch Share 2 from vendor server
// 3. HMAC verification (~25µs)
// 4. XorIDA reconstruction (~50µs)
// 5. Execute reconstructed code
// 6. Memory purge (~20µs)
// Total overhead: <2ms (Tier 1/2)

Fast Onboarding: 3 Acceleration Levels

Traditional algorithm protection requires manual key generation, share distribution setup, and heartbeat server configuration. Unstealable Code collapses this to 15 seconds with zero-click accept, 90 seconds with one-line CLI, and 10 minutes with deploy buttons.

// .env file
USC_INVITE_CODE=USC-abc123

// Auto-accept on first use
import { deployUnstealableCode } from '@private.me/unstealable-code';

const result = await deployUnstealableCode({
  source: algorithmBytes,
  exports: ['calculatePrice'],
  packageName: '@vendor/pricing',
  packageVersion: '1.0.0'
});
// ✅ Invite auto-accepted, ready to deploy

# Install and initialize
npx @private.me/unstealable-code init

# Output:
# ✅ Vendor DID generated
# ✅ Saved to .env
# ✅ Heartbeat server configured
# Ready to deploy algorithms

# Deploy your first package
npx @private.me/unstealable-code deploy \
  --source ./pricing.js \
  --exports calculatePrice \
  --package @vendor/pricing

Example: Zero-Click Accept

Set invite code in environment, deploy algorithm on first use. No manual setup required.

// 1. Set environment variable
// .env file:
USC_INVITE_CODE=https://usc.private.me/invite/USC-abc123

// 2. Deploy algorithm (auto-accepts invite)
import { deployUnstealableCode } from '@private.me/unstealable-code';

const source = new TextEncoder().encode(`
  function calculatePrice(quantity) {
    return quantity * 99.99;
  }
`);

const result = await deployUnstealableCode({
  source,
  exports: ['calculatePrice'],
  packageName: '@vendor/pricing-engine',
  packageVersion: '1.0.0',
  onProgress: (percent, msg) => console.log(`[${percent}%]`, msg)
});

if (result.ok) {
  console.log('✅ Algorithm protected');
  console.log('✅ Customer share ready for npm publish');
  console.log('✅ Vendor share encrypted at rest');
}

// What happened:
// 1. Invite auto-accepted from USC_INVITE_CODE env var
// 2. Vendor DID generated and saved to .env
// 3. Algorithm split via XorIDA (2-of-2)
// 4. Customer share packaged for npm distribution
// 5. Vendor share encrypted with AES-256-GCM
// Total time: ~15 seconds

Example: CLI Setup

One command generates vendor DID, saves credentials, and deploys your first protected algorithm.

# Step 1: Install CLI globally
npm install -g @private.me/unstealable-code

# Step 2: Initialize (generates vendor DID, saves to .env)
unstealable-code init

# Output:
# Generating vendor DID...
# ✅ Vendor DID: did:key:z6Mk...
# ✅ Saved to .env
# ✅ Heartbeat server configured: https://usc.private.me
# Ready to deploy algorithms

# Step 3: Deploy your first package
unstealable-code deploy \
  --source ./pricing-engine.js \
  --exports calculatePrice \
  --package @vendor/pricing-engine \
  --version 1.0.0

# Output:
# [0%] Validating configuration...
# [20%] Splitting algorithm via XorIDA...
# [70%] Packaging customer share for npm...
# [100%] Deployment complete
#
# ✅ Algorithm split (2-of-2)
# ✅ Customer share: ./dist/customer.share
# ✅ Vendor share encrypted at rest
# Ready to publish: npm publish

# Total time: ~90 seconds

Example: Deploy Button

Click one button to provision heartbeat server, vendor share storage, customer invite dashboard, and usage analytics on Vercel/Netlify/Railway.

DEPLOY BUTTONS

After deployment:
• Environment variables auto-configured
• Vendor DID auto-generated
• Ready to deploy algorithms immediately
• Total setup time: ~10 minutes

The Problem: $70B+ Annual Piracy

Traditional algorithm protection fails because it assumes code exists on the client. If it exists, it can be copied.

Why Existing Protection Fails

Obfuscation is reversible. Rename variables, inline functions, encrypt strings — all defeated by patient reverse engineering. Tools like IDA Pro, Ghidra, and binary diffing automate deobfuscation.

DRM is bypassable. License checks get patched out. Hardware dongles get cloned. Even trusted platform modules (TPM) can be attacked via bus snooping or firmware exploits.

Code signing proves source, not usage rights. A validly signed binary can still be pirated. Signatures don't prevent unauthorized execution — they only prove the publisher.

Credential sharing is undetectable. API keys, license files, and activation codes get shared on forums. Vendors can't distinguish legitimate multi-device use from piracy.

The Cost of Piracy

Solution: Code That Cannot Exist Without Vendor

Three-layer cryptographic defense prevents execution of pirated copies. Code distribution, execution, and verification are all cryptographically bound to vendor authorization.

How It Works: Build to Runtime

1. Build Time: Algorithms marked for protection are split via XorIDA at build time. Share 1 packaged with npm, Share 2 encrypted and stored on vendor servers. Zero-knowledge proofs generated and published alongside packages.

2. Installation: Customers install npm packages containing Share 1, manifests, and proofs. Zero-knowledge proofs are publicly verifiable — anyone can verify correctness without seeing source code.

3. Runtime Authorization: First function call establishes session via DID authentication. Heartbeat checks every 30 seconds verify active subscription. Share 2 fetched from vendor server with 30-second TTL.

4. Ephemeral Execution: HMAC verification (~25µs), XorIDA reconstruction (~50µs), execute, memory purge (~20µs). Total overhead under 2ms. Tier 3 skips reconstruction — executes on shares via MPC (~100ms).

Why XorIDA is uniquely qualified

XorIDA offers capabilities no other cryptographic approach can match for unstealable code distribution: information-theoretic security, zero key management, sub-millisecond reconstruction, and mathematical billing enforcement.

Information-Theoretic Security vs. Computational Security

Most encryption relies on computational security — the assumption that attackers don't have enough computing power to break it. AES-256, RSA, and elliptic curve cryptography are all computationally secure. They're safe today, but may become vulnerable if quantum computers advance or mathematical breakthroughs occur.

XorIDA provides information-theoretic security — a mathematical guarantee that Share 1 alone reveals nothing about the original algorithm. An attacker with infinite resources, analyzing Share 1 for eternity, learns zero bits of information. This is the same security level as a one-time pad.

Sub-Millisecond Reconstruction

Piracy prevention cannot sacrifice performance. XorIDA reconstruction takes ~75µs for typical algorithms — fast enough for real-time execution with negligible overhead.

XorIDA is 500-2,000× faster than Shamir's for the same information-theoretic security level. Only XorIDA makes ephemeral per-call reconstruction viable for production workloads.

No Key Management Overhead

Traditional encryption requires key generation, distribution, rotation, and revocation. Keys must be stored securely. If a key is compromised, all encrypted algorithms are at risk. Organizations spend millions on key management infrastructure (HSMs, KMS, key escrow).

XorIDA threshold sharing has no keys. The shares themselves are the only secret material. There's nothing to rotate, nothing to revoke, nothing to store in an HSM. When subscription lapses, Share 2 is simply not delivered. When subscription renews, Share 2 delivery resumes. No key ceremony, no emergency rotation, no compromise recovery procedure.

Mathematical Billing Enforcement

License keys can be copied. DRM can be cracked. Online activation can be bypassed. But XorIDA makes piracy mathematically impossible:

• Share 1 alone is useless: Customer's npm package contains cryptographic noise. It cannot be reverse-engineered because there's nothing to reverse.
• No Share 2 = no execution: Without vendor's Share 2, reconstruction is mathematically impossible. The algorithm literally doesn't exist.
• No bypass vector: Cracking the code requires breaking information-theoretic security — impossible even with infinite computing power.

This creates cryptographic billing enforcement. Payment control is a mathematical property, not a policy that can be circumvented.

Quantum-Proof Guarantee

Post-quantum cryptography (PQC) algorithms like ML-KEM and ML-DSA are believed to resist quantum attacks, but they rely on mathematical assumptions (lattice hardness). If those assumptions are broken, PQC fails.

XorIDA's security is not based on assumptions. It's provably secure against all adversaries, including quantum computers, because Share 1 alone contains zero information about the algorithm. No amount of quantum computing power changes this mathematical fact.

Technology Comparison

Why Obfuscation Alone Fails

Code obfuscation makes reverse engineering harder, but not impossible. Renaming variables, inlining functions, encrypting strings — all are defeated by patient reverse engineering. Tools like IDA Pro, Ghidra, and binary diffing automate deobfuscation.

Obfuscation is delay, not prevention. High-value algorithms (trading bots, ML models, pricing engines) justify unlimited reverse-engineering budgets. An attacker with 6 months and a skilled reverse engineer will extract the algorithm.

XorIDA + Obfuscation = Defense-in-Depth. Unstealable Code supports Tier 3.5: Software Hardened — combining XorIDA (information-theoretic share security) with obfuscation (computational code protection) and anti-tamper detection (runtime debugger detection). This creates maximum software-only protection:

1. XorIDA splitting: Share 1 is cryptographic noise (information-theoretic)
2. Code obfuscation: Reconstructed algorithm is heavily obfuscated (computational)
3. Anti-tamper detection: Debugger attempts trigger self-destruct (runtime)
4. Ephemeral execution: Algorithm purged from memory after <100µs exposure
5. Heartbeat authorization: Vendor controls Share 2 delivery (billing enforcement)

Use Tier 3.5 when: Customer environment is adversarial (competitor using your algorithm), algorithm is high-value IP (pricing models, ML weights), pure software protection required (no TEE/HSM available).

Performance impact: Obfuscated code executes 2-5× slower than original (acceptable for most use cases). XorIDA reconstruction remains ~75µs.

Real-World Use Cases

Five high-value scenarios where algorithm theft prevention justifies the infrastructure cost.

Solution Architecture

Three building blocks compose to create unstealable code: xgit (distribution), xghost (execution), xprove (verification).

Three-Layer Cryptographic Defense

Each layer provides independent security. Compromise of any single layer does not break the system.

Layer 1: xgit (Session-Gated Distribution)

Algorithms split via XorIDA at build time. Share 1 (cryptographic noise) distributed via npm packages. Share 2 encrypted at rest on vendor servers with AES-256-GCM.

Authentication: DID-based session establishment required before Share 2 access. Session tokens expire after 2-24 hours depending on tier. Payment status verified on every heartbeat.

Attack resistance: Attacker who steals npm package gets Share 1 only — mathematically useless alone. Attacker who compromises vendor server gets encrypted Share 2 — requires session keys bound to active DID.

Layer 2: xghost (Ephemeral Execution)

Code reconstructs only at runtime. Execution happens in isolated context, then memory is purged. Three tiers control exposure window:

Tier 3 MPC execution: Code never reconstructs. Execution happens via secure multi-party computation on shares. Customers see only inputs/outputs — never algorithm logic. ~100ms overhead for garbled circuit evaluation.

Layer 3: xprove (Verifiable Black-Box)

Zero-knowledge proofs (KKW protocol) allow verification of algorithm properties without source access. Proofs are ~50KB per function at 128-bit security.

What can be proven: Test coverage percentage, compliance with regulatory rules (SEC market manipulation, FDA validation protocols), absence of backdoors, performance guarantees (max latency, memory bounds), deterministic behavior (same inputs → same outputs).

Who can verify: Regulators (SEC, FDA, NIST), auditors (SOC 2, ISO 27001), customers (procurement verification), courts (patent disputes, trade secret litigation).

Ephemeral Execution Cycle

Code exists only during execution. Full cycle under 2ms for Tier 1/2, ~105ms for Tier 3 MPC.

// Application calls protected function
const result = await tradingStrategy(marketData);

// Under the hood:
// T+0ms:    Heartbeat check (cached 30s, ~5ms on miss)
// T+5ms:    Fetch Share 2 from vendor (30s TTL)
// T+25ms:   HMAC verification (~25µs)
// T+25.05ms: XorIDA reconstruction (~50µs)
// T+25.1ms: Execute reconstructed algorithm
// T+Xms:    Memory purge (~20µs)
// Total: <2ms overhead + algorithm execution time

Heartbeat Protocol

Every 30 seconds, SDK sends heartbeat to vendor server. Server verifies payment status, subscription tier, and geographic restrictions. Response includes updated TTL and feature flags.

Failure modes: If heartbeat fails (network down, payment lapsed, subscription expired), cached Share 2 expires after 30 seconds. All subsequent function calls fail immediately. No offline mode by design.

Memory Purge

After execution completes, reconstructed code is overwritten with cryptographic random data (~20µs). JavaScript heap allocation patterns make recovery difficult — V8 garbage collector runs asynchronously and unpredictably.

Attack window: Tier 1/2 expose code for ~50µs (reconstruction) + execution time + ~20µs (purge). Tier 3 eliminates this window entirely via MPC execution on shares.

Deployment Tiers

Three tiers balance security, performance, and cost. All tiers provide instant global revocation.

Choosing a Tier

Tier 1: Sufficient for most commercial software. Prevents casual piracy, credential sharing, and license key leaks. Instant revocation on subscription expiry.

Tier 2: Adds usage-based billing and payment enforcement. Ideal for ML inference ($X per 1000 predictions), simulation runs ($X per FEA solve), or API-style licensing.

Tier 3.5: Maximum software-only protection via defense-in-depth: XorIDA (information-theoretic shares) + code obfuscation (control flow flattening, string encryption, identifier mangling) + anti-tamper detection (debugger/memory scanner detection with self-destruct). Use when customer environment is adversarial (competitor running your code) or algorithm is high-value IP (pricing models, ML weights). Performance impact: 2-5× slower execution due to obfuscation.

Tier 4: For algorithms worth stealing by nation-states or industrial espionage. Code never exists plaintext — executes on shares via garbled circuits. Accept ~100ms overhead for algorithms that run infrequently or are high-value enough to justify cost.

Integration Patterns

Three integration points: build configuration, deployment credentials, runtime initialization.

Build Configuration

{
  "unstealable": {
    "tier": 2,
    "algorithms": [
      { "path": "./src/trading-strategy.ts", "scope": "proprietary" },
      { "path": "./src/risk-model.ts", "scope": "risk" }
    ],
    "vendor": "https://shares.vendor.com",
    "proofGeneration": true
  }
}

Runtime Initialization

import { initUnstealable } from '@private.me/unstealable-code';

// One-time initialization on app start
await initUnstealable({
  did: process.env.CUSTOMER_DID,
  sessionKey: process.env.SESSION_KEY,
  vendorUrl: 'https://shares.vendor.com',
  tier: 2,
});

// Protected functions now work transparently
const trades = await tradingStrategy(marketData);

Deployment Credentials

Customers receive DID + session key during onboarding. Session keys rotate every 30 days automatically. Old keys remain valid for 7-day grace period to allow zero-downtime rotation.

Security Properties

Attack resistance across eight threat vectors. Tier 3 eliminates memory dump risk entirely.

Key Security Distinctions

Information-theoretic vs computational: XorIDA split is information-theoretic — Share 1 alone reveals exactly zero bits about the algorithm. AES-256-GCM encryption of Share 2 is computational — breakable in theory with enough computing power. Attackers must compromise BOTH.

Tier 3 eliminates code exposure: MPC execution means code never exists in plaintext. Customers execute on garbled circuits. Even with full memory dump, attacker sees only circuit garbling — not algorithm logic.

Behavioral analysis remains possible: All tiers allow attackers to observe inputs/outputs. Statistical analysis can infer algorithm behavior. Not a leak of proprietary code, but a leak of behavioral fingerprints. Mitigate via output noise, rate limiting, or Tier 3 MPC.

Performance Benchmarks

Measured on typical workloads: ML inference (100KB model), trading algorithm (10ms execution), simulation (100ms execution).

Tier 1/2 Overhead Breakdown

Tier 3 MPC Overhead

Real-World Impact

Acceptable use cases: Tier 1/2 suitable for algorithms with >10ms execution time. Tier 3 suitable for algorithms with >100ms execution time or where security justifies 2x overhead.

Unacceptable use cases: Sub-millisecond hot paths (tight loops, per-pixel shaders, packet processing). Overhead dominates execution time. Consider coarser-grained protection (per-frame vs per-pixel, per-session vs per-packet).

Honest Limitations

Unstealable Code is not a silver bullet. Eight scenarios where it does not apply or has reduced effectiveness.

What This Does NOT Protect Against

1. Behavioral cloning via black-box analysis. Attackers with extensive I/O access can build substitute algorithms that behave similarly. This is fundamentally unfixable — any system that produces outputs can be approximated.

2. Insider threats with legitimate access. Employees with valid credentials can execute algorithms and observe behavior. Credential theft = algorithm access. Mitigate via audit logs, least-privilege scopes, and multi-party approval for sensitive operations.

3. Side-channel attacks (timing, power, cache). Execution time variations can leak information about algorithm structure. Power consumption analysis can distinguish code paths. Cache timing attacks can infer memory access patterns. Tier 3 MPC mitigates but does not eliminate.

4. Sub-millisecond hot paths. Overhead is unacceptable for tight loops, per-pixel shaders, or packet processing. Protect coarser-grained operations (per-frame vs per-pixel, per-session vs per-packet).

5. Offline or air-gapped environments. Heartbeat requires network connectivity every 30 seconds. No offline mode by design. Unusable for submarines, aircraft, or secure facilities without internet.

6. Open-source or transparent algorithms. If algorithm logic must be auditable by third parties (cryptographic primitives, voting systems, safety-critical systems), this approach is inappropriate.

7. Algorithms that fit in L1 cache. If entire algorithm + data fit in CPU cache (~32KB), reconstruction overhead dominates. Memory purge is ineffective — attacker can snapshot cache state.

8. Low-margin products. Infrastructure cost (vendor servers, bandwidth, support) only justified for high-value algorithms. Not economical for $10/month SaaS products unless user base is massive.

When NOT to Use This

Instant Global Revocation

Share 2 TTL enables instant termination of all algorithm access worldwide. No software updates required.

When a subscription lapses, contract terminates, or security breach is detected, vendor revokes Share 2 access server-side. All active clients lose access within 30 seconds (TTL expiry). No need to push updates, recall licenses, or notify users.

Revocation Scenarios

Payment failure: Tier 2/3 bind sessions to payment status. Stripe webhook fires on failed payment → vendor marks session as revoked → next heartbeat fails → Share 2 cache expires → all function calls fail.

Contract termination: Enterprise customer contract ends → admin marks organization as revoked → all employee sessions invalidated → algorithm access terminates globally within 30 seconds.

Security breach: Credential leak detected → vendor rotates all session keys → forces re-authentication → attackers locked out immediately, legitimate users re-authenticate seamlessly.

Geographic restrictions: ITAR violation detected (customer accessed from prohibited jurisdiction) → IP geolocation triggers revocation → Share 2 access denied → algorithm stops working.

Usage-Based Billing

Tier 2/3 support per-invocation billing. Vendors charge based on actual algorithm usage, not flat subscriptions.

Every protected function call increments a usage counter. Vendor server aggregates counts per customer per billing period. Stripe invoices generated monthly based on actual usage.

Billing Models

Implementation

SDK tracks usage client-side with tamper-evident HMAC chain. Every 100 invocations or 5 minutes (whichever comes first), SDK submits usage report to vendor. Server verifies HMAC chain, aggregates counts, and updates billing database.

Tamper resistance: Usage reports are HMAC-chained to prevent replay or manipulation. Each report includes nonce, timestamp, cumulative count, and HMAC over previous report. Server detects gaps, resets, or replays.

Compliance Verification via Zero-Knowledge Proofs

Regulators and auditors verify algorithm properties without accessing source code. KKW proofs at 128-bit security, ~50KB per function.

What Can Be Proven

Test coverage: Prove algorithm has >95% line coverage and >90% branch coverage without revealing test cases or code structure.

Regulatory compliance: Prove trading algorithm does NOT engage in market manipulation patterns (wash trading, spoofing, layering) as defined by SEC Rule 10b-5 without revealing strategy logic.

Performance guarantees: Prove algorithm completes in <100ms for all valid inputs and uses <1GB memory without revealing implementation.

Determinism: Prove same inputs always produce same outputs (critical for audits, debugging, regulatory investigations) without exposing algorithm.

Absence of backdoors: Prove code does NOT contain network exfiltration, hardcoded credentials, or unauthorized data access without source review.

Verification Workflow

1. Vendor generates proofs: At build time, KKW proof generator analyzes protected algorithms and produces zero-knowledge proofs for claimed properties (coverage, compliance, performance).

2. Proofs published publicly: Proofs (~50KB per function) published alongside npm packages. Anyone can download and verify without credentials.

3. Auditor verifies: FDA auditor downloads proof for pharmaceutical algorithm, verifies test coverage claim via KKW verifier (open-source). Verification takes ~100ms, requires zero access to source code.

4. Compliance certification: Auditor issues compliance certificate based on verified proofs. Customer can demonstrate compliance to regulators without exposing trade secrets.