Trust & security

The relay is blind. The keys live on devices. Your storage holds the bytes.

End-to-end encryption isn't a feature toggle, it's how the platform was architected. Per-device X25519 keys, AES-256-GCM payloads, presigned-URL attachments. We forward sealed envelopes — we don't have the keys to open them.

X25519 + AES-256-GCM·Per-device keypairs·Zero plaintext on relay

X25519 + AES-256-GCMper-recipient-device payloads

Per-device keysno shared identity key

Blind relaywe never hold plaintext

BYO storageyour bucket for file bytes

When trust is the product

Where E2EE stops being a feature and becomes a requirement.

Some apps can't survive a breach narrative. The architecture below means there's no plaintext to leak.

Regulated / healthcare

BAA-friendly: nothing in our infra reads, stores, or could leak the message contents. Attachments stay in your HIPAA-bound bucket.

Healthcare · Compliance

Finance & regulated industries

SEC / FINRA / MiFID-friendly: compliance exports stay encrypted, custody stays with your firm, audit trail is yours alone.

Finance · Compliance

Privacy-first consumer apps

Signal / Threema-class privacy in your own brand. Per-device revoke, retention you control, no metadata leakage.

Consumer · Privacy

Why DropOnAir for trust

Trust is the architecture, not the marketing copy.

Blind relay by design

The server holds sealed bytes. It cannot decrypt them, so it cannot leak them. Subpoenas hit the same wall everyone else does.

Per-device keypairs

Each device of each user generates its own X25519 keypair. Compromising one device doesn't expose the others. Revoke one key, the rest keep working.

Remote device revoke

Lost phone, ex-employee, suspicious activity — revoke the device key from the panel. The next sealed envelope refuses to deliver to it.

Your storage for file bytes

Attachments go directly to your S3 / GCS / Azure bucket via presigned URLs. No file ever transits our infrastructure.

Under the hood

How a sealed message moves through the platform.

The relay forwards opaque bytes. The crypto is done on the sender's device, once per recipient device. Multi-device receivers each decrypt with their own key — no shared identity secret to leak.

Key generation — every device, on first run, generates an X25519 keypair. The public key registers in the directory; the private key never leaves the device.
Send — sender fetches recipient device public keys, derives a shared secret per device (X25519 ECDH → HKDF-SHA256), encrypts the payload (AES-256-GCM with AAD).
Relay — we store and forward the sealed envelopes. We see metadata (sender, recipient, timestamp) but never the contents.
Receive — recipient device opens its own envelope. Multi-device users get one envelope per device, each decryptable only by its key.
Revoke — mark a device key invalid via the panel or API. The directory refuses to mint new envelopes for it; the device stops being a recipient.

Encryption isn't an option

E2EE is the default path. There's no insecure mode by accident.

The SDK handles key generation, key fetch, encrypt, decrypt. Your code doesn't touch raw crypto.

Device trust in the SDK →

// SDK generates a device key on first init
const client = await initialize({ appId, getUserJwt });

// sendMessage is E2EE by default. No opt-in flag.
await client.sendMessage(toUserId, "highly sensitive");

// Revoke a lost device — sealed envelopes stop delivering to it
await client.revokeDevice(deviceId);

What you ship

A trust posture you can put in a security review.

X25519 ECDH + AES-256-GCM end-to-end encryption
Per-device keypairs, generated on first run
Public-key directory with revoke + rotation
Blind-relay forwarding — server never holds keys
Per-device decryption on multi-device users
Remote device revoke (panel + API)
Attachments via presigned URLs to your bucket
Audit-friendly per-message metadata only

Ready to lock down

Ship the trust posture before the breach narrative.

Blind relay + per-device keys + your storage. One SDK away.

Read the quick-start Device trust in the SDK