xTrust: Trust Registry & Key Verification

The Problem

Every secure channel starts with one question: whose key is this? Get the answer wrong and nothing that follows matters — encryption protects the wrong conversation.

Conventional PKI solves identity binding with certificate authorities. But CAs are centralized trust anchors. One compromised CA invalidates every certificate it ever issued. The 2011 DigiNotar breach, the 2015 CNNIC incident, and the ongoing Let's Encrypt phishing certificate problem all demonstrate the same structural failure: delegated trust collapses at scale.

PGP's Web of Trust tried to decentralize the problem but created its own: key signing parties, manual fingerprint comparison, incomprehensible trust paths, and a UX so hostile that even security researchers get it wrong. After three decades, PGP adoption among non-specialists remains negligible.

Modern messengers like Signal improved the UX with safety numbers, but the verification model is still manual, optional, and per-conversation. Most users never verify. When a contact changes devices, Signal silently accepts the new key with a small notification that most users dismiss.

Key rotation makes everything worse. When a user gets a new phone, their old key pair is gone. Every contact must re-verify. Most systems handle this by silently accepting the new key — the exact behavior an attacker would exploit. Without cryptographic continuity proofs, there is no way to distinguish a legitimate device change from a man-in-the-middle attack.

The Old Way

The PRIVATE.ME Solution

xTrust replaces centralized certificate authorities with a four-layer trust stack: automatic TOFU registration, mutual SAS verification ceremonies, append-only transparency logs, and continuity-proven key rotation.

When a contact's public key is first encountered, xTrust accepts it automatically with TOFU (Trust on First Use) trust level and records the event in a SHA-256 hash-chained transparency log. If the key is seen again, it matches. If a different key appears for the same identity, xTrust raises a FINGERPRINT_CONFLICT warning — the cryptographic equivalent of "this person's identity has changed."

Trust can be upgraded from tofu to verified via a mutual key verification ceremony. Both parties derive a 6-word Short Authentication String (SAS) from their fingerprints using HMAC-SHA256. They compare the SAS over a separate channel (in person, phone, video). If the words match, the key binding is cryptographically confirmed.

When keys rotate (new device, scheduled rotation, key compromise), the old private key signs the new public key to create a continuity proof. Contacts can verify the rotation was authorized by the key holder, not a MITM attacker. A configurable grace period (default 7 days) accepts both old and new keys during transition.

Every trust-relevant event — key registration, SAS verification, rotation, revocation — is recorded in an append-only transparency log where each entry is SHA-256 hash-chained to the previous. Tampering with any entry breaks the chain. Auditors can verify the complete key history for any contact without accessing message content or key material.

The New Way

Architecture

Four modules, each handling one dimension of trust. They compose together but each works independently.

Module 1: TofuManager

Manages trust-on-first-use for contacts. When processKey(email, fingerprint) is called, TofuManager checks its in-memory contact map. New keys are accepted with tofu trust level. Matching keys return the existing trust state. Changed keys return FINGERPRINT_CONFLICT — the application decides whether to warn the user or auto-reject. Trust can be upgraded to verified via upgradeTrust(email, fingerprint) after a successful verification ceremony.

Module 2: Key Verification Ceremony

Implements QR code + Short Authentication String (SAS) verification for mutual key confirmation. Both parties' public key fingerprints are computed via SHA-256, then fed into HMAC-SHA256 to derive a 6-word human-readable SAS from a 256-word PGP-style wordlist. A challenge is created with a 15-minute TTL, a unique ID from crypto.getRandomValues(), and QR data encoding both fingerprints. Both parties compare the SAS phrase over a separate channel. If they match, the key binding is confirmed.

The SAS wordlist uses a PGP-style approach where each byte maps to one of 256 words (e.g., "aardvark", "arctic", "beacon", "cipher", "glacier"). Six words provide 48 bits of entropy — enough for a human to compare in under 10 seconds. The probability of a MITM attacker guessing the correct SAS is 1 in 281 trillion.

Module 3: KeyTransparencyLog

Append-only cryptographic log where every key event (registration, rotation, verification, revocation) is recorded with a SHA-256 hash chain linking each entry to the previous one. Each entry contains the contact email, public key fingerprint, action type, timestamp, and optional metadata. verifyChain(contactEmail) walks the chain and confirms every previousEntryHash is correct. If any entry has been tampered with, the chain breaks.

Module 4: KeyRotationManager

Handles key rotation with continuity proofs. When a contact rotates their key pair, the old private key signs the new public key using ML-DSA-65 (FIPS 204 post-quantum signature). The initiateRotation() method verifies the continuity proof, computes fingerprints for both keys, logs the event to the transparency log, and starts a configurable grace period (default 7 days). During the grace period, both the old and new fingerprints are accepted by isAccepted().

Competitive Failure Analysis

Every trust model makes tradeoffs. Here is where each one fails — and how xTrust avoids the same failure modes.

Benchmarks

Trust operations are fast enough to be invisible. Key lookups are sub-microsecond. Verification ceremonies complete in milliseconds. Transparency log audits scale linearly with chain length.

Measured on commodity hardware (4-core, 3.2 GHz). Web Crypto API for SHA-256 and HMAC. ML-DSA-65 via mldsa-wasm. All operations single-threaded.

ACI Surface

Eight core functions organized into four modules. Every function returns Result<T, TrustError> or a simple value — no exceptions thrown.

TofuManager

Key Verification

Transparency Log

Key Rotation

Use Cases

Regulatory Alignment

xTrust addresses key management requirements across major compliance frameworks. The transparency log provides the audit trail that regulators demand.

Cross-ACI Integration

xTrust is the identity binding layer that other ACIs depend on. When an ACI needs to know whose key it is talking to, xTrust provides the answer.

xBind (Agent SDK)

Every xBind channel begins with a DID handshake. xTrust's TofuManager registers the remote DID's signing key on first connection. Subsequent connections verify the key matches. If the remote agent rotates their key, the continuity proof is verified before the channel is established. The transparency log records every key event for every xBind peer.

xFuse (Threshold Identity Fusion)

xFuse's verify step in the 5-stage pipeline calls xTrust to confirm that each signal provider's key is trusted before accepting their identity signals. A FINGERPRINT_CONFLICT from xTrust halts the pipeline — the system will not fuse identity signals from an unverified source.

xID (Digital Identity)

xID's ephemeral DIDs are derived from a master seed, but verifiers need to confirm the DID belongs to the claimed identity. xTrust's transparency log records the binding between each DID and the master public key. When a DID rotates (epoch-based), the continuity proof is logged and the grace period prevents verification failures during transition.

xGate (Rate Limiting)

xGate's PerDidLimiter uses DID identifiers as rate limit keys. xTrust resolves whether a DID is trusted, verified, or unknown — enabling different rate limits per trust level. Verified contacts might get higher limits while TOFU contacts get stricter throttling.

xLock (Push Authentication)

xLock's push-based 1-tap authentication relies on device key binding. xTrust's TOFU registration accepts the device key on first setup. When a user gets a new device, the old device signs the new device's key via xTrust's continuity proof, allowing a seamless device transition without requiring the user to re-verify on every service.

import { TofuManager, KeyTransparencyLog } from '@private.me/xtrust';
import { Agent } from '@private.me/xbind';

// Initialize trust registry
const log = new KeyTransparencyLog();
const tofu = new TofuManager(log);

// On xBind channel open, verify remote agent's key
const result = await tofu.processKey(
  remoteDid,
  remoteFingerprint
);

if (!result.ok) {
  // FINGERPRINT_CONFLICT: key changed unexpectedly
  throw new Error(`Trust violation: ${result.error.message}`);
}

Security Properties

Ship Proofs, Not Source

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

Use Cases

Honest Limitations

xTrust is a trust registry, not a replacement for all PKI. Understanding its boundaries helps you deploy it correctly.

Enterprise HTTP Server

A turn-key HTTP server that wraps the xTrust core for organizations needing a managed, multi-team trust registry. One binary launches the listener, replays state from append-only JSONL stores, enforces three RBAC roles, and exposes the full xTrust capability surface as REST — with a hash-chained transparency log behind every endpoint.

The SDK described above is exactly right inside one application. It is exactly the wrong shape when an entire enterprise needs to share one canonical key registry. Multi-team deployments break the in-memory model: contact A's TOFU registration in the trading-desk app is invisible to the compliance app two floors down, library calls cannot be audited from the outside, and key history disappears on process restart. The Enterprise HTTP Server solves all three by lifting @private.me/xtrust into a single long-running process with persistent storage, RBAC, and an HTTP query surface auditors can point at.

Architecture

A thin HTTP layer over the xTrust core, backed by five JSONL stores and gated by three RBAC roles. No database. No external dependency. One process. Inbound requests pass through three middleware layers: API-key authentication, role-based authorization, and per-key rate limiting (1000 requests per minute by default). Every endpoint delegates to the underlying library — TofuManager for key registration, KeyTransparencyLog for the append-only audit chain, KeyRotationManager for continuity-proven rotation, and the SAS verification helpers for mutual key confirmation. The server adds nothing to the cryptographic story; it only wraps it.

State persists across restarts via append-only JSONL files. On boot, each file is replayed into an in-memory Map for sub-millisecond reads. On every write, the new record is appended to disk before the in-memory map is updated, so a crash never leaves the maps ahead of the log. The data directory is the database.

Technical Highlights

REST Endpoints

Eleven endpoints organized into five capability groups. Every request is authenticated by API key, authorized by role, and rate-limited per key.

Health

Key Registration & Verification

Key Rotation

Transparency Log

RBAC Management

RBAC Model

Three roles, one bootstrap key, and SHA-256 hashing for every credential at rest. The principle is least privilege by default.

Enterprise Use Cases

Deployment

One binary, one data directory, one port. Container-friendly. Air-gap-friendly.

# Required
export TRUST_ADMIN_KEY=$(openssl rand -hex 32)

# Optional (defaults shown)
export TRUST_PORT=3700
export TRUST_DATA_DIR=./data
export TRUST_LOG_FORMAT=json
export TRUST_MERKLE_ALGORITHM=sha256

# Install
pnpm add @private.me/xtrust

# Start the server
xtrust serve --port 3700 --data ./data

# Output
Trust server listening on port 3700
Data directory: ./data
Admin API key configured

docker run -d \
  --name xtrust \
  -p 3700:3700 \
  -v /var/data/trust:/app/data \
  -e TRUST_ADMIN_KEY=<bootstrap-key> \
  -e TRUST_LOG_FORMAT=json \
  privateme/xtrust:latest

curl -X POST http://localhost:3700/keys \
  -H "Authorization: Bearer $TRUST_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{"did":"did:key:z6MkUser","publicKey":"<base64>"}'

Server Security Properties

Server Limitations

Verifiable Trust Operations

Every trust operation in this ACI produces a verifiable audit trail via xProve. HMAC-chained integrity proofs let auditors confirm that keys were registered, verified, and rotated correctly — without accessing the keys themselves.

Ready to deploy xTrust?

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

import {
  TofuManager,
  KeyTransparencyLog,
  KeyRotationManager,
  createChallenge,
  computeFingerprint,
  deriveSas,
} from '@private.me/xtrust';

// Initialize the trust stack
const log = new KeyTransparencyLog();
const tofu = new TofuManager(log);
const rotation = new KeyRotationManager(log);

// Register a contact's key (TOFU)
const fp = await computeFingerprint(contactPublicKey);
const trust = await tofu.processKey(
  'alice@example.com',
  fp
);
// trust.value.trustLevel === 'tofu'

// Upgrade to verified via SAS ceremony
const challenge = await createChallenge(
  'bob@example.com',
  'alice@example.com',
  myPublicKey,
  contactPublicKey
);
// challenge.value.shortAuthString === "arctic comet glacier..."
// Compare over phone/video, then:
await tofu.upgradeTrust('alice@example.com', fp);
// trust.value.trustLevel === 'verified'

Purchase Endpoint

Programmatic subscription creation via REST API. Supports both email-based and xBind identity-based purchases.

Endpoint

POST https://private.me/api/aci/checkout

Request Body

interface PurchaseRequest {
  // Product identification (required)
  productId: 'xtrust';
  tier: 'pro' | 'enterprise';

  // Customer identification (one required)
  email?: string;              // Email-based purchase
  did?: string;                // xBind identity-based purchase

  // Optional metadata
  metadata?: Record<string, string>;
}

Response

interface PurchaseResponse {
  checkoutUrl: string;         // Stripe Checkout session URL
  sessionId: string;           // Stripe session ID
  expiresAt: string;           // ISO 8601 timestamp
}

Error Response (RFC 7807)

All errors follow RFC 7807 Problem Details for HTTP APIs format.

interface ProblemDetails {
  type: string;                // URI identifying the problem type
  title: string;               // Human-readable summary
  status: number;              // HTTP status code
  detail?: string;             // Detailed explanation
  instance?: string;           // URI reference to specific occurrence
}

Example: Email-Based Purchase

const response = await fetch('https://private.me/api/aci/checkout', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    productId: 'xtrust',
    tier: 'pro',
    email: 'user@example.com'
  })
});

const { checkoutUrl } = await response.json();
// Redirect user to checkoutUrl for payment
window.location.href = checkoutUrl;

Example: xBind Identity Purchase

import { Agent } from '@private.me/xbind';

// Create agent identity
const agent = await Agent.quickstart({ name: 'purchase-agent' });

// Purchase using agent DID (email optional)
const envelope = await agent.send(
  'did:web:private.me',
  {
    productId: 'xtrust',
    tier: 'pro',
    did: agent.did
    // email optional - fallback generated if missing
  }
);

const response = await fetch('https://private.me/api/aci/checkout', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(envelope)
});

const { checkoutUrl } = await response.json();
// Higher rate limit: 60/min (vs 10/min for email-based)