Deaddrop: Threshold Secret Drops

The Problem: Centralized Trust in Secret Exchange

Every existing approach to secret exchange requires trusting a server, a relay, or a network with the complete secret at some point during transit. That single point of trust is a single point of failure.

Signal disappearing messages still route through centralized servers that see metadata — who sent what, when, and to whom. OnionShare depends on Tor relay integrity and requires both parties to be online simultaneously. ProtonMail performs server-side encryption — your keys exist on their infrastructure, accessible to a subpoena or insider. Self-destructing links rely on the host server to actually delete the content and typically leave traces in CDN caches, backup systems, and access logs. In every case, a compromise at the center exposes everything.

The fundamental flaw is architectural: the complete secret exists in one place at one time. Any system that centralizes the secret — even temporarily — creates a window where a single breach, subpoena, or insider threat exposes the entire payload.

Competitive Failure Table

Deaddrop eliminates centralized trust entirely. The secret is split before it leaves the sender. No single channel, server, or intermediary ever holds enough information to reconstruct.

The Root Cause

The problem is not weak encryption or poor key management. The problem is architectural centralization. Every approach in the table above creates a moment where the complete secret exists in a single location — a server, a relay, an endpoint. That moment is the vulnerability. Increasing key length does not help. Switching algorithms does not help. The only solution is to ensure the complete secret never exists in transit at all.

Deaddrop inverts the model: instead of encrypting a secret and routing it through a trusted channel, the secret is split into mathematically independent fragments that travel through untrusted channels. The security comes from the splitting, not from the channels. Each channel can be fully compromised — monitored, logged, intercepted — and the adversary learns nothing unless they compromise K channels simultaneously.

This is a paradigm shift from "trust the pipe" to "trust the math." The channels are untrusted by design. The security properties hold even against an omniscient network adversary who controls every channel individually but cannot correlate K channels in real time.

The Solution: Split Before Transit

Deaddrop splits secrets using XorIDA threshold sharing into K-of-N shares, wraps each share in a binary envelope with HMAC integrity, encodes for transport, and distributes shares across independent channels. Reconstruction requires collecting any K shares. No server. No relay. No trust.

The Pipeline

Six steps transform a secret into transport-ready shares. Each step is pure, deterministic, and independently testable.

1. Serialize. The input secret (arbitrary bytes, string, or structured data) is normalized to a Uint8Array. Strings are UTF-8 encoded. Structured data is JSON-serialized then encoded.

2. Pad. PKCS7 padding ensures the payload aligns to the block size required by XorIDA splitting. Padding is deterministic and reversible — the original length is recoverable from the padded output.

3. HMAC Tag. HMAC-SHA256 is computed over the padded payload. The tag is prepended to the data. This tag is verified before reconstruction — tampered shares are rejected before any XorIDA operation occurs.

4. XorIDA Split. The HMAC-tagged payload is split into N shares using XorIDA threshold sharing over GF(2). Any K shares reconstruct the original. K-1 shares reveal zero information — information-theoretically, not computationally.

5. xFormat Envelope. Each share is wrapped in a binary xFormat envelope (IDA5 magic header 0x49444135) containing the share index, threshold parameters, drop ID, TTL metadata, and the share payload.

6. Base45 Encode. Each enveloped share is Base45-encoded for transport over text-safe channels (email, QR codes, SMS, printable media). Base45 is the ISO/IEC 18004 standard encoding used by EU Digital COVID Certificates — mature, well-tested, and universally decodable. For binary channels (USB, file transfer), this step can be skipped to eliminate the ~37% size overhead.

Why Base45?

Base45 was chosen over Base64 for a specific reason: it is the encoding standard adopted by the EU Digital COVID Certificate system (ISO/IEC 18004), making it the most widely deployed binary-to-text encoding in the world for security-critical payloads. Base45 produces output that is safe for QR codes, SMS, email bodies, chat messages, and printed media without escaping or special handling. The ~37% size overhead (vs ~33% for Base64) is a negligible trade-off for universal transport compatibility.

Architecture

The Deaddrop pipeline transforms a secret into independently distributable shares and back. Every step is reversible, every intermediate is verified.

Split Pipeline

Reconstruct Pipeline

xFormat Binary Envelope

Each share is wrapped in an xFormat binary envelope before encoding. The envelope structure is:

The magic header enables quick identification of Deaddrop shares without parsing the full envelope. Corrupted or non-Deaddrop data is rejected at the first 4 bytes.

Multi-Channel Distribution

Deep Dive: Share Distribution

K-of-N threshold semantics give Deaddrop its power. The sender chooses how many shares to create (N), how many are needed to reconstruct (K), and which channels carry each share. The recipient collects K shares from any K channels.

Threshold Semantics

2-of-2: Both shares required. Maximum security, zero redundancy. If either share is lost, the secret is irrecoverable. Ideal for two-person integrity (TPI) scenarios: nuclear launch codes, dual-key cryptographic ceremonies, escrow release. Both parties must cooperate. Neither can act alone.

2-of-3: Any two of three shares reconstruct. One share can be lost or destroyed without data loss. The most common configuration — balances security with operational resilience. One share provides redundancy against channel failure, physical loss, or custodian unavailability.

3-of-5: Any three of five shares reconstruct. Two shares can be lost or compromised. Designed for distributed teams, multi-jurisdiction custody, or scenarios where geographic separation introduces transport risk. Five-party custody with three-party reconstruction provides the widest margin for operational failure.

4-of-7: Enterprise-grade custody. Four of seven shares reconstruct. Three shares can be lost. Suitable for board-level secret custody, multi-national legal teams, or critical infrastructure key management where maximum redundancy and maximum collusion resistance are both required.

Channel Independence

Shares can travel via any medium. The transport layer is completely decoupled from the cryptographic layer. Each share is a self-contained, opaque blob with no dependency on the other shares or on any specific transport protocol.

TTL-Based Expiry

Each share carries a TTL (time-to-live) in the xFormat envelope metadata. After the TTL expires, compliant clients reject the share during validation. The secret effectively self-destructs when the last share expires — no server-side deletion required. TTL enforcement is client-side, not server-dependent.

TTL values are configurable per drop:

Share Index Validation

Every share carries its index (1-based) and the threshold parameters (K, N) in the xFormat envelope. Before reconstruction, Deaddrop validates: (a) at least K shares are present, (b) all shares reference the same drop ID, (c) share indices are within range [1, N], (d) no duplicate indices, (e) HMAC verification passes. Malformed or tampered shares are rejected before any XorIDA operation.

Benchmarks

Deaddrop operates at sub-millisecond latency for typical secret payloads. The bottleneck is never the cryptography — it is the transport.

Pipeline Performance

Payload Size Scaling

Comparison with Traditional Approaches

Deaddrop is 2.4x faster than AES-256-GCM at 1 KB and information-theoretically secure — a property no encryption-based approach can match regardless of key length or algorithm choice. The performance advantage comes from XorIDA operating over GF(2) — bitwise XOR, the fastest mathematical operation on binary data. No modular arithmetic, no elliptic curve operations, no polynomial evaluation.

ACI Surface

Six functions compose the complete Deaddrop lifecycle. Every function returns a Result<T, E> — no thrown exceptions.

import { createDrop, collectShare, reconstructDrop } from '@private.me/deaddrop';

// Split a secret into 2-of-3 shares
const secret = new TextEncoder().encode('TOP SECRET: launch codes alpha-7');
const drop = createDrop(secret, {
  threshold: 2,
  shares: 3,
  ttl: 86_400_000, // 24 hours
});

// Distribute shares via independent channels
sendViaEmail(drop.value.encodedShares[0]);   // Share 1 → email
writeToUsb(drop.value.encodedShares[1]);     // Share 2 → USB drive
printAsQr(drop.value.encodedShares[2]);      // Share 3 → QR code

// Recipient collects any 2 shares to reconstruct
const collected = collectShare(drop.value.dropId, emailShare);
const collected2 = collectShare(drop.value.dropId, usbShare);

const result = reconstructDrop([collected.value.share, collected2.value.share]);
// result.value → Uint8Array identical to original secret

Use Cases

Five verticals where threshold secret drops transform operational security from a process into a guarantee.

Regulatory Compliance

Threshold splitting maps directly to regulatory requirements across four frameworks. Each mapping is a structural guarantee, not a configuration option.

GDPR Right to Erasure: Mathematical Proof

Traditional systems answer "delete the data" by marking records in a database and trusting the operator to purge backups, caches, and replicas. This is a promissory guarantee — it depends on correct implementation and honest behavior at every layer.

Deaddrop provides a mathematical guarantee. With a 2-of-3 configuration, deleting any 2 shares makes the secret information-theoretically irrecoverable. No amount of computation — classical, quantum, or future — can recover the secret from a single remaining share. The erasure is not a policy. It is a theorem.

Cross-ACI Composition

Deaddrop composes with four ACIs to form a complete secret distribution infrastructure. Each integration is additive — Deaddrop works standalone, and each composition unlocks new capabilities.

Composition Patterns

Each cross-ACI integration follows the same pattern: Deaddrop handles the split/reconstruct lifecycle, and the composed ACI handles one orthogonal concern (transport, storage, identity, or audit). Integrations are opt-in — Deaddrop works standalone without any of these ACIs. When composed, the combined system inherits the security properties of both layers.

Security Properties

Deaddrop enforces seven security properties by construction. Every property is tested and independently verifiable.

HMAC-First Verification

The integrity verification order is critical and enforced at the code level. When shares arrive for reconstruction, the pipeline executes in strict sequence: (1) decode, (2) unwrap envelope, (3) validate metadata (drop ID, index, TTL), (4) verify HMAC-SHA256, (5) only then XorIDA reconstruct. If any step fails, the pipeline halts and returns a typed error. No partial reconstruction is ever attempted.

Fail-closed behavior: Any validation failure — expired TTL, mismatched drop ID, out-of-range index, failed HMAC — causes the entire reconstruction to fail with a specific error code. The system never produces a "best effort" result. Either the output is byte-identical to the original secret, or the operation fails completely.

Threat Model

Traditional Secret Exchange vs. Deaddrop

Verifiable Secret Operations

Every Deaddrop operation — split, distribute, collect, reconstruct — produces integrity artifacts that xProve can chain into a verifiable audit trail. Prove that secrets were handled correctly without revealing the secrets themselves.

What Gets Audited

Ship Proofs, Not Source

Deaddrop 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

@private.me/deaddrop-cli is a self-hosted secret drop management server — Docker-ready, air-gapped capable, with three-role RBAC, share lifecycle management, and append-only audit logging.

Endpoints

RBAC Roles

Admin — full access: create, destroy, reconstruct, deposit, collect, verify, audit. Full lifecycle control over all drops and shares.
Operator — create drops, deposit and collect shares, verify shares. Cannot destroy drops or read audit logs. Intended for field personnel handling share distribution.
Auditor — read-only: list drops, read metadata, read audit logs. Cannot create, destroy, or handle shares. Intended for compliance officers and security reviewers.

Air-Gapped Deployment

The CLI server operates without any external network dependency. All cryptographic operations are local. No DNS resolution, no certificate validation against external CAs, no telemetry. Deploy in SCIF environments, submarine networks, or any facility where outbound connectivity is prohibited. The Docker image includes all dependencies — no runtime package fetching.

docker build -t deaddrop-cli -f packages/deaddrop-cli/Dockerfile .
docker run -d --name deaddrop -p 4000:4000 \
  -v deaddrop-data:/data \
  -e DEADDROP_ADMIN_KEY=your-secret-key \
  deaddrop-cli

Enhanced Identity with Xid

Deaddrop can optionally integrate with Xid to enable unlinkable anonymous sharing — verifiable within each transfer context, but uncorrelatable across drops, recipients, or time.

Three Identity Modes

How Ephemeral Anonymous Sharing Works

// Initialize Deaddrop with Xid integration
import { DeaddropClient } from '@private.me/deaddrop-cli';
import { XidClient } from '@private.me/xid';

const xid = new XidClient({ mode: 'ephemeral' });
const drop = new DeaddropClient({ identityProvider: xid });

// Each transfer derives unlinkable DIDs automatically
const receipt = await drop.send({
  payload: sensitiveDocument,
  recipient: 'whistleblower-hotline'
});
  → [Deaddrop] Deriving ephemeral sender DID from master seed...
  → [Deaddrop] Sender DID: did:key:z6MkE... (unique to this drop + epoch)
  → [Deaddrop] Deriving ephemeral recipient DID...
  → [Deaddrop] Recipient DID: did:key:z6MkF... (unique to this drop + epoch)
  → [Deaddrop] XorIDA split with ephemeral identities (~50µs)

// Transfer is anonymous with unlinkable DIDs
// Verification works within drop, but cross-transfer correlation fails

Market Positioning

Key Benefits

• Cross-transfer unlinkability — Can't track senders across multiple drops
• Per-drop derivation — Same sender has different DIDs per transfer
• Epoch rotation — DIDs automatically rotate daily/weekly/monthly
• Split-protected derivation — Master seed is XorIDA-split, never reconstructed
• Verifiable anonymity — Prove source authenticity without revealing identity
• Regulatory compliance — Meets whistleblower protection requirements

Get Started

Install Deaddrop, split your first secret, and distribute shares across channels — all in a few lines of code.

npm install @private.me/deaddrop

Requirements

Runtime: Node.js 18+ or any environment supporting Web Crypto API (crypto.getRandomValues). Browser, Deno, Bun, and Cloudflare Workers all supported. No native addons, no WASM, no platform-specific binaries.

Dependencies: Zero runtime dependencies. XorIDA threshold sharing, HMAC-SHA256, PKCS7 padding, xFormat envelope, and Base45 encoding are all implemented internally. No third-party cryptographic libraries. Supply chain attack surface: zero.

TypeScript: Full type definitions included. Strict mode compatible. Every function returns Result<T, E> for explicit error handling without exceptions. No any types. All error variants are enumerated and documented.

Bundle size: Under 15 KB gzipped. Suitable for edge deployment, serverless functions, and mobile applications where bundle size matters.

import {
  createDrop,
  collectShare,
  reconstructDrop,
  verifyShare,
} from '@private.me/deaddrop';

// 1. Create a 2-of-3 drop
const secret = new TextEncoder().encode('CLASSIFIED: operation nightfall');
const drop = createDrop(secret, {
  threshold: 2,
  shares: 3,
  ttl: 3_600_000, // 1 hour
});

// 2. Distribute shares via independent channels
const [share1, share2, share3] = drop.value.encodedShares;
// share1 → email channel A
// share2 → USB dead drop
// share3 → QR code (redundancy)

// 3. Verify a share before collecting
const valid = verifyShare(decodedShare);
// valid.value → true (integrity + TTL + index OK)

// 4. Collect any 2 shares and reconstruct
const result = reconstructDrop([shareA, shareB]);
// result.value → Uint8Array identical to original
const plaintext = new TextDecoder().decode(result.value);
// "CLASSIFIED: operation nightfall"

Ready to deploy Deaddrop?

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