XorIDA: Threshold Sharing Engine

The Problem: Cryptographic Data Protection Is Broken

Traditional approaches to protecting data at rest and in transit force a choice between security and performance. Key-based encryption requires key management. Secret sharing is computationally expensive. The industry accepted this tradeoff. It was wrong.

Key management is the single biggest failure point in data security. AES-256-GCM is mathematically sound, but it requires a key. That key must be generated, stored, rotated, distributed, escrowed, backed up, and eventually destroyed. Every step is an attack surface. Every key is a single point of failure. Compromise one key and you compromise every byte it ever encrypted.

Secret sharing solved key management but introduced a performance problem. Shamir's Secret Sharing operates over large finite fields with polynomial evaluation. For every byte of data, it performs expensive modular arithmetic. The result: 500-2000x slower than direct encryption. This made threshold sharing impractical for real-time applications — messaging, streaming, API payloads, and anything latency-sensitive.

Modern crypto libraries compound the risk. A typical npm cryptographic package pulls in dozens of transitive dependencies. Each dependency is an attack surface. A single compromised package in the chain undermines the entire security model. The npm ecosystem has repeatedly demonstrated this risk — event-stream, ua-parser-js, colors.js. Dependency count is attack surface.

Competitive Failure Table

XorIDA is 1,000x faster than Shamir's for small payloads and achieves the same information-theoretic guarantee. No key management. No dependency chain. No tradeoff.

The Old Way

The Solution: XorIDA Threshold Sharing

XorIDA implements Information Dispersal over GF(2), achieving information-theoretic security with near-zero computational overhead. The split IS the security. No keys to manage, rotate, or compromise. Unbreakable even with infinite compute.

By operating over GF(2) — the binary field — XorIDA replaces expensive modular arithmetic with XOR operations that execute in a single CPU cycle. The Cauchy matrix construction ensures any K-of-N share subset can reconstruct the original data, providing both secrecy and fault tolerance simultaneously.

Information-theoretic security means the security guarantee is mathematical, not computational. It does not depend on the difficulty of factoring large numbers, solving discrete logarithms, or any other computational hardness assumption. An adversary with infinite computing power, infinite time, and infinite storage cannot extract the original data from fewer than K shares. This is not a claim about current hardware. It is a proof about information.

No keys. XorIDA does not use encryption keys. There is no key to generate, store, rotate, distribute, escrow, back up, or destroy. The data is split into N shares. Any K shares reconstruct it. Any K-1 shares reveal zero information about it. The absence of keys eliminates the largest attack surface in data protection.

Zero dependencies. The implementation is pure TypeScript with zero npm dependencies. Every random byte comes from crypto.getRandomValues(). HMAC-SHA256 verification uses the Web Crypto API. TLV serialization is built in. The entire package has 100% line coverage with known-answer test vectors, property-based tests, and fuzz tests.

The New Way

Architecture: The Split Pipeline

The XorIDA pipeline takes arbitrary binary input, pads it to a K-aligned boundary, computes an HMAC-SHA256 integrity tag, multiplies the padded data by a Cauchy matrix over GF(2) to produce N shares, and attaches per-share HMAC tags. Reconstruction is the reverse: verify HMACs, invert the matrix, unpad.

Split Pipeline

Reconstruct Pipeline

IDA5 Binary Envelope Format

Every XorIDA share is wrapped in the IDA5 binary envelope. The first 4 bytes are the magic number 0x49444135 ("IDA5" in ASCII), followed by the share index, threshold parameters, and HMAC tag. This self-describing format enables any recipient to identify a share without external metadata and validate its integrity before processing.

// IDA5 binary envelope layout
// Bytes 0-3:    Magic    0x49444135 ("IDA5")
// Byte  4:      Version  0x01
// Byte  5:      Index    Share index (1-based)
// Byte  6:      K        Threshold
// Byte  7:      N        Total shares
// Bytes 8-39:   HMAC     SHA-256 integrity tag
// Bytes 40-55:  UUID     Share set identifier
// Bytes 56+:    Data     Share payload

Deep Dive: GF(2) Operations

XorIDA's performance advantage comes from operating over GF(2) — the binary field where addition and subtraction are both XOR, and every non-zero element is its own inverse. This reduces matrix operations from expensive modular arithmetic to single-cycle CPU instructions.

Threshold Parameters (K-of-N)

The threshold parameter K determines how many shares are required to reconstruct. The total N determines how many shares are produced. Any K shares out of N suffice for reconstruction. Any K-1 shares reveal zero information about the original data. This is the information-theoretic guarantee.

Why GF(2)?

XOR-based splitting. In GF(2), addition is XOR. Multiplication of a byte by a GF(2) element is a conditional XOR. There is no modular reduction, no polynomial evaluation, no large-number arithmetic. The Cauchy matrix over GF(2) has the property that every square sub-matrix is invertible, which guarantees that any K shares can reconstruct the original data.

1:1 expansion ratio. Each share is the same size as the original data divided by K. For a 2-of-3 split of 100 bytes, each share is approximately 50 bytes. Total storage for all 3 shares: ~150 bytes. Compare to Shamir's, where each share is the full size of the original data: 3 shares of 100 bytes = 300 bytes. XorIDA uses 50% less storage for the same redundancy level.

HMAC-before-reconstruction. Every share carries an HMAC-SHA256 tag computed via the Web Crypto API. Before reconstruction begins, every collected share is verified against its tag. If any share has been tampered with — even a single bit — the operation fails immediately. The engine never attempts to reconstruct from unverified shares. This prevents both accidental corruption and deliberate manipulation.

Configuration Examples

import { split, reconstruct } from '@private.me/crypto';

// 2-of-2: Maximum security, no fault tolerance
// Both shares required. Loss of either = data loss.
const shares2of2 = await split(data, 2, 2);

// 2-of-3: Security + one-share fault tolerance
// Any 2 of 3 shares reconstruct. Lose 1, still recover.
const shares2of3 = await split(data, 3, 2);

// 3-of-5: Enterprise redundancy
// Any 3 of 5 shares. Survive loss of 2 shares.
const shares3of5 = await split(data, 5, 3);

// Reconstruct from any valid K-subset
const original = await reconstruct([shares3of5[0], shares3of5[2], shares3of5[4]]);
// original === data (byte-identical)

Benchmarks

XorIDA dominates AES-256-GCM for API-sized payloads: 2-11x faster below 1KB. The crossover occurs at approximately 1-2KB. Above that, AES catches up because it benefits from hardware acceleration (AES-NI). XorIDA is purpose-built for the payload sizes that matter most: API requests, credentials, keys, tokens, and messages.

XorIDA vs. AES-256-GCM

Why This Matters

Most security-critical payloads are small: API tokens (64-256B), JWTs (256B-1KB), session keys (32-64B), credentials (100B-1KB), chat messages (100B-4KB). XorIDA operates in exactly the range where traditional approaches are slowest. For the payload sizes that matter most — the ones securing every other operation — XorIDA is an order of magnitude faster.

ACI Surface

Four core functions. That is the entire public API. Split, reconstruct, tag, verify. Every other PRIVATE.ME package builds on these four primitives.

import { split, reconstruct } from '@private.me/crypto';

// Split: data in, shares out
const data = new TextEncoder().encode('sensitive API payload');
const shares = await split(data, 3, 2);
// shares.length === 3
// Each share reveals zero information about the payload

// Reconstruct: any K shares in, original data out
const recovered = await reconstruct([shares[0], shares[2]]);
// recovered === data (byte-identical)

// Tampered share? Rejected before reconstruction.
shares[0].data[0] ^= 0xff; // flip bits
const result = await reconstruct([shares[0], shares[1]]);
// throws: HMAC verification failed

Use Cases

Five domains where XorIDA's combination of speed, key-free security, and information-theoretic guarantees enables capabilities that key-based cryptography cannot.

Defense and Intelligence

For government agencies and defense contractors handling classified information or Controlled Unclassified Information (CUI), XorIDA provides multi-level security by construction. No computational hardness assumptions means no quantum timeline risk — critical for information that must remain classified for decades. No key management means no key escrow disputes under CALEA or CLOUD Act.

Financial Services Compliance

For broker-dealers, registered investment advisors, and financial institutions subject to SEC, FINRA, SOX, and PCI DSS requirements, XorIDA provides tamper-evident record protection with mathematically provable integrity guarantees.

Regulatory Compliance

XorIDA's information-theoretic security model aligns with or exceeds the requirements of major regulatory frameworks. No key management means no key escrow disputes. No computational hardness assumptions means no quantum timeline risk.

Data Sovereignty

XorIDA enables data sovereignty by construction. Split sensitive data and store shares in different legal jurisdictions. Share 1 in the EU (GDPR jurisdiction), Share 2 in the US (CLOUD Act jurisdiction), Share 3 in Switzerland. No single jurisdiction holds enough to compel disclosure. A legal subpoena in one country produces a share that reveals zero information about the original data. Cross-border data protection becomes a mathematical property, not a legal argument.

For multinational enterprises subject to conflicting data localization requirements (GDPR vs. CLOUD Act, China PIPL, India DPDPA), XorIDA provides a technical mechanism that satisfies all frameworks simultaneously: the data is both "stored" in each jurisdiction (as shares) and "not stored" in any jurisdiction (as reconstructable content).

GDPR Article 5: Data Minimization

GDPR Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary" for the specified purpose. XorIDA enables data minimization by construction: each share, when held independently, contains zero information about the original data. Organizations can distribute shares to different processors while ensuring no single processor holds data that could be used to identify individuals. This aligns with the principle of proportionality — the split ensures that data processing is strictly limited to what is necessary.

For cross-border transfers under GDPR Chapter V, XorIDA provides a technical safeguard: shares stored in third countries outside the EU reveal no personal data. A legal subpoena or government access request in one jurisdiction produces a share that is mathematically useless without the threshold number of shares. This technical measure supports Standard Contractual Clauses (SCCs) and demonstrates compliance with the "appropriate safeguards" requirement.

EU Cyber Resilience Act: IoT Cryptographic Protection

The EU Cyber Resilience Act (Regulation 2024/2847), entering force in phases through 2027, establishes binding cybersecurity requirements for products with digital elements. The regulation mandates cryptography following international guidelines (NIST SP 800-57, SOGIS, ETSI TS 119 312, BSI TR-02102-1). Starting December 2027, manufacturers must provide timely security updates and implement data protection by default.

XorIDA satisfies CRA requirements through information-theoretic security that exceeds computational cryptography standards. For IoT devices with constrained environments, XorIDA's zero-dependency implementation (no OpenSSL, no external crypto libraries) reduces supply chain risk. The sub-millisecond performance enables real-time splitting and reconstruction on embedded devices. HMAC-SHA256 integrity verification aligns with approved cryptographic mechanisms. The shift toward hardware-based trust using TPMs and secure elements complements XorIDA: split the device firmware with XorIDA, store shares across independent channels, and use the TPM to protect the reconstruction key schedule.

FINRA Rule 4511: Financial Record Retention

FINRA Rule 4511 requires broker-dealers to preserve books and records for at least six years in a format compliant with SEC Rule 17a-4. Records must be stored in a tamper-evident, non-rewritable, non-erasable format (WORM compliance). XorIDA provides a complementary security layer: split financial records with 2-of-3 threshold, store shares in independent WORM systems (one in SEC-regulated storage, one in a geographically separate location, one in an offline backup).

No single storage system compromise exposes reconstructable records. Insider threats are mitigated: an employee with access to one storage system cannot reconstruct transaction data. For audit purposes, the HMAC chain on each share provides tamper evidence. Combined with xProve's verifiable computation tier, firms can demonstrate cryptographic proof that records have not been altered — satisfying both SEC 17a-4's integrity requirements and SOX Section 404 internal control mandates.

SOX Section 404: Internal Controls Over Financial Reporting

Sarbanes-Oxley Act Section 404 requires management to assess the effectiveness of internal controls over financial reporting. XorIDA supports SOX compliance by eliminating single points of failure in financial data protection. Split general ledger data, transaction logs, and audit trails with 2-of-3 threshold. No single database compromise exposes financial records. No single employee (including database administrators) can reconstruct sensitive data without threshold cooperation.

The zero-dependency implementation reduces supply chain risk (SOX Section 404 control environment). The 100% test coverage and verifiable split/reconstruct operations provide audit evidence of control effectiveness. For public companies subject to external auditor attestation (SOX 404(b)), the HMAC chain and xProve verification tiers provide cryptographic proof of data integrity — stronger evidence than traditional access control logs.

Defense and Classified Information

For government contractors handling Controlled Unclassified Information (CUI) under NIST SP 800-171 or classified information under ICD 503, XorIDA provides multi-level security by construction. Split classified documents with 2-of-2 threshold, store shares on independent networks at different classification levels. Share 1 on SIPRNET, Share 2 on JWICS. No single network compromise exposes the classified content.

The information-theoretic guarantee aligns with NSA's Commercial Solutions for Classified (CSfC) Component List requirements: unconditional security regardless of adversary capabilities. For CMMC Level 3 (Defense Federal Acquisition Regulation Supplement compliance), XorIDA's zero-key architecture eliminates key management requirements under NIST SP 800-171 control 3.13.11 (cryptographic key establishment and management). There are no keys to establish, manage, rotate, or destroy — the split IS the security.

Cross-ACI Composition

XorIDA is the foundation layer. Every PRIVATE.ME ACI builds on these four primitives. Four critical composition patterns define how the ecosystem connects.

Integration Code Examples

All PRIVATE.ME ACIs expose TypeScript APIs designed for composition. The following patterns demonstrate how XorIDA integrates with xLink, xChange, and xCompute for common workflows.

import { Agent } from '@private.me/xlink';
import { split } from '@private.me/crypto';

const agent = await Agent.fromSeed(seed);
const message = new TextEncoder().encode('Confidential report');

// Split message into 2 shares with XorIDA
const shares = await split(message, { threshold: 2, totalShares: 2 });

// Send share[0] via HTTPS, share[1] via WebSocket
await agent.send({
  to: recipientDID,
  payload: shares[0],
  transport: ['https://transport1.example.com']
});

await agent.send({
  to: recipientDID,
  payload: shares[1],
  transport: ['wss://transport2.example.com']
});

// Recipient reconstructs from both shares
const reconstructed = await reconstruct([share0, share1]);

import { encryptWithSplitKey } from '@private.me/xchange';
import { split } from '@private.me/crypto';

// Encrypt 10MB file with AES-256-GCM, split the key
const { ciphertext, keyShares } = await encryptWithSplitKey(largeFile, {
  threshold: 2,
  totalShares: 2
});

// Send key share[0] via channel A, share[1] via channel B
await sendKeyShare(keyShares[0], 'https://channelA.example.com');
await sendKeyShare(keyShares[1], 'https://channelB.example.com');

// Send ciphertext via high-bandwidth channel (S3, CDN, etc.)
await uploadCiphertext(ciphertext, 's3://bucket/object');

// Recipient reconstructs key from both shares, decrypts ciphertext
const key = await reconstructKey([keyShare0, keyShare1]);
const plaintext = await decrypt(ciphertext, key);

import { split } from '@private.me/crypto';
import { addShares, multiplyShares } from '@private.me/xcompute';

// Party A splits secret value
const valueA = new Uint8Array([42]);
const sharesA = await split(valueA, { threshold: 2, totalShares: 2 });

// Party B splits secret value
const valueB = new Uint8Array([17]);
const sharesB = await split(valueB, { threshold: 2, totalShares: 2 });

// Compute (A + B) directly on shares without reconstruction
const sumShares = await addShares(
  [sharesA[0], sharesB[0]],
  [sharesA[1], sharesB[1]]
);

// Result is itself XorIDA shares — reconstruct to reveal sum
const sum = await reconstruct(sumShares); // [59]

// No party ever saw the other's input value

Enterprise Mode: xLink + xChange + xProve

For enterprise deployments requiring compliance audit trails, combine all three ACIs: xLink for authenticated agent identity, xChange for fast key transport, and xProve for verifiable computation proofs. The resulting pipeline provides split-channel communication with cryptographic proof of correct handling — no single component compromise exposes data, and every operation is auditable without revealing plaintext.

import { Agent } from '@private.me/xlink';
import { encryptWithSplitKey } from '@private.me/xchange';
import { proveCorrectSplit } from '@private.me/xprove';

const agent = await Agent.fromSeed(enterpriseSeed);

// Encrypt + split key
const { ciphertext, keyShares, splitProof } =
  await encryptWithSplitKey(sensitiveData, {
    threshold: 2,
    totalShares: 3,
    generateProof: true  // xProve Tier 2 commit-reveal
  });

// Verify split correctness before sending
const isValid = await proveCorrectSplit(splitProof);
if (!isValid) throw new Error('Split verification failed');

// Send via xLink authenticated channels
await agent.send({
  to: backupDID,
  payload: keyShares[0],
  transport: ['https://backup1.example.com']
});

await agent.send({
  to: backupDID,
  payload: keyShares[1],
  transport: ['https://backup2.example.com']
});

// Audit trail: log proof to compliance system
await auditLog.record({
  operation: 'split-key-backup',
  proof: splitProof,
  timestamp: Date.now()
});

Security Properties

Six security properties enforced by construction. Not by policy. Not by configuration. By the mathematics of the implementation.

Defense in Depth

XorIDA is not a replacement for encryption — it is a different security primitive that provides guarantees encryption cannot. The recommended defense-in-depth pattern combines both: encrypt data for confidentiality during transit (TLS, AES-256-GCM), then split the decrypted data with XorIDA for protection at rest. Each layer addresses a different threat model. Encryption protects against eavesdroppers. XorIDA protects against storage compromise, insider threats, and key management failures.

For the highest security, layer XorIDA splitting with xLink's hybrid post-quantum key exchange (X25519 + ML-KEM-768) and dual signatures (Ed25519 + ML-DSA-65). The transport layer is quantum-resistant by computation. The storage layer is quantum-resistant by information theory. No single breakthrough compromises both simultaneously.

Traditional Encryption vs. XorIDA

Verifiable Split/Reconstruct Operations

Every XorIDA operation — split, reconstruct, HMAC verify — produces integrity artifacts that xProve can chain into a verifiable audit trail. Prove that data was split correctly, that shares were not tampered with, and that reconstruction produced the correct output — all without revealing the underlying data.

Ship Proofs, Not Source

Crypto generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.

Use Cases

Honest Limitations

Honest engineering requires honest documentation. Four known limitations with their mitigations.

Enterprise CLI

XorIDA powers 21 enterprise CLI servers in the Enterprise CLI Suite. Each server is Docker-ready, air-gapped capable, and deployable in classified environments. The crypto engine runs identically on-premises, in the cloud, or in air-gapped facilities.

Every enterprise CLI server in the suite — from xLink agent communication to xFuse threshold identity fusion to xStore split storage — depends on @private.me/crypto as its foundational layer. The zero-dependency design means the crypto engine can be deployed in air-gapped environments without package registry access. Docker images are self-contained.

Key Enterprise CLIs Powered by XorIDA

docker build -t xlink-cli -f packages/xlink-cli/Dockerfile .
docker run -d --name xlink -p 3300:3300 \
  -v xlink-data:/data \
  -e XLINK_ADMIN_KEY=your-secret-key \
  xlink-cli

# All 21 CLI servers share the same @private.me/crypto engine
# Zero external dependencies in the crypto path
# Air-gapped: no npm registry needed at runtime

Get Started

Install the crypto engine, split your first payload, and reconstruct it — all in a few lines of code. Pure TypeScript means universal runtime compatibility.

Platform Compatibility

npm install @private.me/crypto

import { split, reconstruct } from '@private.me/crypto';

// 1. Encode your sensitive data
const data = new TextEncoder().encode('sensitive API payload');

// 2. Split into 3 shares, threshold 2
const shares = await split(data, 3, 2);
// shares.length === 3
// Each share: { index, data, hmac }
// Any single share reveals ZERO information

// 3. Distribute shares to independent locations
// Share 1 -> AWS S3
// Share 2 -> Azure Blob
// Share 3 -> Local encrypted volume

// 4. Reconstruct from any 2 shares
const recovered = await reconstruct([shares[0], shares[2]]);
// recovered === data (byte-identical)

// 5. HMAC verification is automatic
// Tampered shares are rejected before reconstruction
// No configuration needed. Fail-closed by default.

import { split, reconstruct } from '@private.me/crypto';

const secret = new TextEncoder().encode('master signing key');

// 2-of-2: Split-channel (Xail email, xLink M2M)
const twoOfTwo = await split(secret, 2, 2);

// 2-of-3: Standard backup with fault tolerance
const twoOfThree = await split(secret, 3, 2);

// 3-of-5: Enterprise redundancy
const threeOfFive = await split(secret, 5, 3);

// 4-of-7: Maximum enterprise redundancy
const fourOfSeven = await split(secret, 7, 4);

// All configurations: sub-millisecond for typical payloads
// All configurations: information-theoretic security
// All configurations: HMAC-verified reconstruction

Ready to deploy XorIDA?

Talk to Sol, our AI platform engineer, or book a live demo with our team.