Previously Veil Private Messenger. Because of trademark issues with the name Veil, we've rebranded to Vardum ahead of our independent audit. Same app, same team, same encryption.
VardumPrivate messaging

Architecture

We built a messenger whose database can't hold your messages

Vardum is zero-knowledge by structure, not by promise. The database that runs Vardum has no column, table or file where a readable message could exist. Compel what the service holds and you get ciphertext, public routing material and operational metadata: no readable content and no private keys.

The design rule

Every privacy messenger eventually faces the question "can you read my messages?" Most answer with a policy. We answered with a data model. The rule we coded against:

If a piece of information could embarrass, incriminate or identify a user, the backend must never receive it in a form it can read, or never receive it at all.

The system that came out of it has three separated parts:

  • Your phone: all encryption and decryption. Keys live in memory or the phone's secure storage and never travel to the server.
  • The relay, owned and run by Vardum: stores and routes ciphertext it can't open. How the relay works
  • The identity layer: accounts and published public keys, kept apart from message keys. It checks signatures and never sees conversation content.

What the server can see: the whole list

Privacy marketing that claims "we see nothing" isn't telling you the truth. Here's Vardum's actual list. It's shorter than most people expect, but it isn't zero:

  • A sign-in label. New accounts have no email or phone number: the app makes a random-looking label and a hidden password from your 24 words, on your phone. It's sign-in data, not encrypted content.
  • Handles and routing. The relay delivers between Vardum IDs, so it must know enough to deliver. A Vardum ID is a random 16-character label you can replace in one tap, and every new chat gets fresh keys.
  • That blobs are moving, roughly when. Vardum sends cover traffic, so a single observation doesn't reveal which envelopes are real. Traffic correlated at large scale is a different story; that limit is stated below.

Server sees

  • Sign-in label
  • Vardum ID (replaceable)
  • Public key material
  • Ciphertext envelopes
  • IVs and minimal routing data
  • Encrypted vault files
  • Timestamps of activity

Only your phone holds

  • Private keys
  • Session and thread keys
  • Plaintext, in memory and in transit only
  • Vault passphrases
  • Whether a hidden volume exists
  • Your contacts

How destruction actually works

Most apps "delete" a message by hiding it. Vardum deletes it, in two stages.

Stage 1: the two message clocks. Burn after opening runs 5 minutes to 24 hours after the person opens the message. Unopened messages expire 12, 24, 36 or 48 hours after sending, with a separate 30-day tier for the Founding Tester Forum. A sweeper removes expired records every 2 minutes.

Stage 2: on close. Close the thread, from either side, with one tap, and everything is hard-deleted on the spot: every message, every file binding, the session record itself.

And burned messages look the same as cover traffic, so the server can't even tell which messages were real.

The vaults, briefly

Every vault is a fixed-size block of random-looking bytes with no headers or markers. Files sit in encrypted slots, and unused space is random noise. A second passphrase can open a hidden volume inside it, with nothing pointing to it. We don't claim resistance to statistical analysis (NC-01). What the design gives you is deniability: hand over the outer passphrase under pressure and there's nothing to read inside it.

The labelling convention

Every security claim we make is labelled Implemented New or Not claimed. Nothing implied, nothing overstated. Post-quantum key agreement uses ML-KEM-768 (FIPS 203) mixed with ECDH P-256, with X25519 signed prekeys for contact sessions, recorded as Implemented and self-reviewed. The full list is in the claims register.

The threat model, stated plainly

Vardum protects against

  • Server seizure or compromise: nothing readable to take
  • Demands for content: nothing readable to hand over
  • Passive network interception: end-to-end with hybrid post-quantum keys
  • Coerced disclosure of a vault: that's what hidden volumes are for
  • A compromised peer phone: either side can wipe the thread from the relay

Vardum doesn't (yet) protect against

  • Malware on your phone: no messenger survives a compromised device
  • Messages someone already read and copied: no app can un-read
  • A global observer correlating traffic at scale: cover traffic raises the cost but doesn't erase the pattern

Anyone who tells you their app solves all three is selling you something.

We put SimpleX above ourselves

We scored the ten leading encrypted messengers on eight criteria and published the result, every score sourced. On messaging, SimpleX comes first and Vardum second, just ahead of Signal. SimpleX and Signal win on independent review and years of public scrutiny, and they've earned it. Where Vardum leads, by a long way, is protecting your whole phone: seized-phone protection, identity privacy and everything beyond messaging. See the comparison

Vardum's cryptography is self-reviewed today, and an independent cryptographic audit is planned for early 2027. We'd genuinely rather you attack the architecture than compliment the interface. Questions, especially hostile ones, are welcome.

— Matt, founder