Core Concepts

What is XorIDA?

XorIDA is a threshold secret sharing algorithm operating over the binary field GF(2). It splits data into shares such that any k shares can reconstruct the original, but fewer than k shares reveal nothing. Unlike encryption, XorIDA provides information-theoretic security — mathematically provable protection that cannot be broken, even with unlimited computational power.

This makes XorIDA ideal for machine-to-machine communication, split-channel protocols, and any scenario where encryption keys create operational risk. Private.Me builds all 205 ACIs on this foundation.

How it works

XorIDA threshold sharing involves four critical steps. Each step must execute in order for secure reconstruction.

1. Split The original data is encoded into n shares using XOR operations over GF(2). Each share is the same size as the original. Any k shares can reconstruct the original via XOR combination.
2. Distribute Shares are transmitted over separate channels. For example, in a 2-of-2 protocol, share 1 goes via email while share 2 goes via SMS. An attacker seeing only one channel gains zero information about the original data.
3. HMAC Verify After reconstruction, the HMAC-SHA256 signature is verified on the reconstructed data. This ensures the reconstructed data was not tampered with. If verification fails, the data is rejected before unpadding.
4. Reconstruct Once all k shares are verified, they are XOR-combined to recover the original data. The result is bit-for-bit identical to the original input.

Why not Shamir's Secret Sharing?

Shamir's Secret Sharing is the most widely known threshold scheme, but it operates over large prime fields and requires computationally expensive modular arithmetic. XorIDA operates over GF(2), using only XOR — the simplest and fastest operation.

Both schemes provide information-theoretic security. XorIDA is chosen for speed, simplicity, and zero key management. Shamir's is documented in the Private.Me patent as an alternative embodiment, but is not implemented in production.

Agent identity

Private.Me agents use Ed25519 for signing and X25519 for Diffie-Hellman key agreement. Each agent has a self-certifying decentralized identifier (DID) in the did:key format. No central registry, no certificate authority, no trust anchor required.

The DID is derived directly from the agent's Ed25519 public key using multibase encoding. It looks like this:

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

This provides non-repudiation (every message is cryptographically signed) and forward secrecy (ephemeral X25519 keys are generated per-session using ECDH, then discarded after use). The combination ensures that even if an agent's signing key is compromised, past sessions remain secure.

Example: Creating an agent

const agent = await Agent.create()
console.log(agent.did)
// did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

The agent's identity is its DID. All authentication, authorization, and message verification use this DID as the trust root. No API keys, no bearer tokens, no shared secrets.

Envelope format

Every Private.Me message is wrapped in a standardized envelope format called Envelope V1. The envelope uses encrypt-then-sign — the payload is encrypted with AES-256-GCM, then the entire envelope (including encrypted ciphertext) is signed with Ed25519.

Envelope structure:

The envelope is serialized using Type-Length-Value (TLV) encoding for wire transmission. The first 4 bytes are the magic number 0x49444135 ("IDA5" in ASCII), which identifies the format as an XorIDA share envelope.

On the receiving side, the signature is verified first, then the HMAC, then the ciphertext is decrypted. If any verification step fails, the envelope is rejected before reconstruction begins.

See it in action