Docs / Concepts

How XorIDA works

XorIDA threshold sharing over GF(2). Information-theoretic security — not computational. No keys to manage, no quantum threat.

What is XorIDA?

Threshold Sharing

XorIDA implements threshold secret sharing over the binary Galois field GF(2). Unlike computational security (RSA, AES), XorIDA provides information-theoretic security — even an attacker with infinite computing power cannot reconstruct a message from fewer than k shares.

k-of-n threshold: Any k shares reconstruct; fewer than k reveal nothing
Sub-millisecond for typical payloads: Linear-time XOR operations, no modular arithmetic
No keys: The shares ARE the security — nothing to steal, rotate, or escrow
Quantum-proof: Security is unconditional, not based on mathematical hardness

Original message

plaintext (1 MB)

↓ SPLIT (n=3)

↓ RECONSTRUCT (k=2)

Any 2 of 3 shares

↓

plaintext (1 MB)

Share 2 alone = random noise. Zero information leaked.

How it works

The Process

Split

The plaintext is split into n shares using XOR operations over GF(2). Each share is the same size as the original data. The operation is O(n) — linear time, dominated by memory-speed XOR. For typical payloads (1-10KB), this completes in sub-millisecond time. At API payload sizes (64B–1KB), a full XorIDA roundtrip is 2–11× faster than hardware-accelerated AES-256-GCM.

Distribute

Shares are sent across independent channels — email providers, direct connections, gateways. No single channel carries enough information to reconstruct. Each share is indistinguishable from random noise without the other shares.

HMAC Verify

Before reconstruction, every share is verified with HMAC-SHA256. This happens BEFORE the data is assembled — if any share has been tampered with, it is rejected. Verification is non-negotiable and cannot be bypassed.

Reconstruct

Any k-of-n verified shares combine via XOR to produce the original plaintext. The operation is deterministic and instant. No decryption key is needed — the shares themselves are the only secret.

HMAC verification MUST happen before reconstruction. No exceptions. This is the single most important security invariant in the system. A tampered share could produce corrupted output if assembled without verification.

Why not Shamir's?

Comparison

Shamir's Secret Sharing is well-known but impractical at scale. XorIDA achieves the same threshold guarantee with fundamentally different performance characteristics.

Property	Shamir's SSS	XorIDA (Ours)
Field	PRIME GF(p), large prime	BINARY GF(2), native XOR
Speed (1 MB)	SLOW 500 – 2,000 ms	FAST ~33 ms
Operations	HEAVY Polynomial interpolation	MINIMAL XOR only
Share size	Same as secret	Same as secret
Embedded (8-bit)	IMPRACTICAL Big-integer arithmetic	NATIVE Bit-level operations
Key management	REQUIRED Polynomial coefficients	NONE Shares are the security
Quantum-proof	Theoretically yes	UNCONDITIONAL Information-theoretic
Patent status	Public domain	PATENT-PENDING Proprietary implementation

Agent identity

Identity

Every agent gets a Decentralized Identifier (DID) backed by Ed25519 (signing) and X25519 (key agreement) keys generated via Web Crypto API. The DID format is did:key:z6Mk... — self-certifying, no registry required.

The Ed25519 key signs every envelope, providing non-repudiation and sender verification. The X25519 key enables ephemeral ECDH key agreement for forward-secret encryption between any two agents.

identity.ts

import { Agent } from '@xail/agent-sdk';

const agent = await Agent.create();

// Ed25519 signing key (DID)
agent.did  // did:key:z6MkhaXg...

// X25519 key agreement (ECDH)
const shared = await agent.agree(recipientDid);

Persistence
Node 20 does not support raw Ed25519 private key export. Use exportPKCS8() / importFromPKCS8() to persist identities across process restarts. For full identity restoration (including the X25519 key), use importIdentity() with both PKCS8 blobs.

“The Agent class is a thin orchestrator, not a monolith. Identity, envelopes, transport, trust registry, nonce store — each module works independently. Our hand-written BigInt Ed25519 on an ARM microcontroller produces byte-identical DIDs to the SDK's Web Crypto implementation. That's not an accident.”

— Vault Engineering Team

Envelope format

Envelope V1

Messages are encrypted with AES-256-GCM (encrypt-then-sign pattern). The envelope carries share metadata fields enabling split-channel delivery.

envelope-v1.ts

{
  version: 1,
  sender:    'did:key:z6Mk...',
  recipient: 'did:key:z6Mr...',
  encrypted: Uint8Array,  // AES-256-GCM ciphertext
  signature: Uint8Array,  // Ed25519 signature
  nonce:     Uint8Array,  // 12-byte IV
  shareIndex: 0,          // which share (0-based)
  shareCount: 3,          // total shares (n)
  threshold:  2,          // required shares (k)
  hmac:      Uint8Array   // HMAC-SHA256
}

See it in action

Split, tamper, verify, reconstruct — all in your browser.

Open playground →