How beep works

Zero-knowledge secret sharing built on proven cryptographic primitives.

Share flow

Client encrypts your secret with AES-256-GCM using the Web Crypto API. A random 256-bit key is generated in the browser.

Ciphertext is stored server-side. The encryption key stays in the URL fragment (#key) which is never sent to the server.

Recipient decrypts client-side using the key from the URL fragment. If burn-after-reading is on, the server deletes the ciphertext after one retrieval.

Split flow

Client encrypts the secret with AES-256-GCM, same as Share.

Server encodes the ciphertext into N shards using Reed-Solomon erasure coding. Any K-of-N shards can reconstruct the original.

Commitment is returned — a 36-byte value embedding the Merkle root (SHA-256) and the K/N configuration. Each shard gets its own URL.

Reconstruction requires the commitment plus K shard URLs. The server verifies each shard against the Merkle root before decoding.

Sign flow

Client encrypts the secret with AES-256-GCM, same as Share.

Server signs the ciphertext with a fresh ephemeral Ed25519 keypair, using a domain-separated namespace (beep_secret_v1).

Recipient sees a verification badge. The server re-verifies the signature on retrieval to confirm the ciphertext hasn't been tampered with.

Security properties

Property	Detail
Zero-knowledge	The server never sees plaintext. Encryption keys exist only in URL fragments.
Forward secrecy	Each secret uses a unique AES-256-GCM key. Each signature uses an ephemeral Ed25519 keypair.
Integrity	AES-GCM is an authenticated cipher — tampered ciphertext fails decryption. Signed secrets add Ed25519 verification. Shards are verified against a Merkle root.
Ephemeral	All data is in-memory with configurable TTL (max 1 week). A background reaper purges expired entries every 60s.
Domain separation	Ed25519 signatures are bound to the `beep_secret_v1` namespace, preventing cross-protocol replay.

Cryptographic primitives

AES-256-GCM

Authenticated encryption for all secrets. Performed entirely client-side via the Web Crypto API.

NIST SP 800-38D

Ed25519

Elliptic-curve digital signatures for the Sign offering. Ephemeral keypair per secret.

RFC 8032

Reed-Solomon erasure coding

K-of-N secret splitting with Merkle tree commitments for shard integrity verification.

Reed & Solomon, 1960

SHA-256

Merkle root commitments for shard integrity. Also used for secret ID generation.

FIPS 180-4

Libraries & tools

commonware-cryptography

Ed25519 key generation, signing, and verification. SHA-256 hashing.

2026.4

commonware-coding

Reed-Solomon erasure coding with Merkle tree commitments.

2026.4

commonware-codec

Deterministic binary serialization for shards and cryptographic types.

2026.4

Axum

Async HTTP framework built on Tokio. Handles all API routing and request extraction.

0.8

Web Crypto API

Browser-native AES-256-GCM encryption. No JavaScript crypto libraries needed.

W3C

Commitment format

The 36-byte commitment returned by Split encodes everything needed for reconstruction:

Bytes	Content
0..2	min_shards (K) as big-endian u16
2..4	total_shards (N) as big-endian u16
4..36	SHA-256 Merkle root of the encoded shards

This makes reconstruction self-contained — the commitment carries both the erasure coding configuration and the integrity proof. No external metadata is needed.