Claims register
Every claim, labelled
Each security claim Vardum makes, with its status and its limits side by side. If any other page conflicts with this register, the register wins.
Native product · veil-ratchet-4 · Updated 16 October 2026An independent cryptographic audit is planned for early 2027. Until it's published, nothing here is a completed independent assurance. The code is public under AGPL-3.0 at github.com/VeilPrivate/VEIL.
Implemented built and in the current app · New recently added, with caution notes · Verified, not claimed tested on our own phones, not yet in a released build · Not claimed things we deliberately don't promise
Messaging
Message payloads are encrypted on-device with per-message forward secrecy.
veil-ratchet-4 uses a double ratchet with AES-GCM-256, HKDF-SHA256 and hybrid classical plus ML-KEM-768 key agreement. Fresh post-quantum material is mixed in as the ratchet advances. Self-reviewed; an independent audit is planned for early 2027.
Session fingerprints let participants verify their encrypted conversation.
Participants compare the fingerprint through a separate trusted channel. This checks cryptographic keys, not a phone number, email address or real-world identity. A compromised or modified device remains outside this protection.
Invitations can be protected with a passphrase.
An optional passphrase is mixed into key derivation on both phones and never sent to the relay. Share it through a separate channel. It protects the invitation, not proof of a real-world identity.
Padding and cover traffic reduce message-size and timing inference.
Messages use fixed-size padding buckets and decoy envelopes while a session is open. Network request sizes, timing and the fact of using the service can still be observed. Media uploads have visible sizes and aren't disguised by message padding.
Pictures and videos are end-to-end encrypted, with a 25 MB per-file cap.
Each file is encrypted on the sender's phone with a fresh AES-GCM-256 key that travels only inside the encrypted message. The relay holds ciphertext and session-to-file routing metadata, not the key. File size and upload and download timing remain observable.
Saved message history is encrypted on-device.
Local history is optional; Nothing at rest keeps no saved conversation keys or message cache. Device compromise, operating-system artefacts and copies a recipient makes remain outside the guarantee.
You choose how this phone keeps conversation keys.
Sealed on the phone, in the Security chip (Secure Enclave, behind Face ID or Touch ID), or Nothing at rest. A phone that keeps usable keys can expose them to software running with enough privileges; these settings don't promise trace-free operation.
Messages follow separate burn-after-open and unopened-lifetime dials.
Burn after opening is 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 forum tier. The burn clock follows the person opening the message, not a background download. Expired ciphertext is discarded on read and removed by the relay's two-minute sweep.
Voice notes use the same end-to-end encrypted media path.
Recorded and encrypted on the phone, with the per-file key carried inside the message. The same 25 MB cap applies. File size and transfer timing remain visible; voice notes are not an internet-calling feature.
A delivery confirmation indicates decryption on the other phone.
Encrypted receipts can confirm delivery. Decryption alone doesn't prove a person read a message, and lost or delayed receipts can leave a missing indicator even when the message arrived.
Quiet threads can end automatically.
The inactivity window (1 hour to 30 days, or never) is a separate control from the unopened-message dial. When it passes, the session records and envelopes are reclaimed by the two-minute sweep.
A session-binding mismatch is surfaced rather than silently accepted.
The app checks that the relay's session public material matches the conversation's established binding. A mismatch stops the session and shows a reason; authenticated decryption rejects altered ciphertext.
Read receipts are opt-in.
Each receiver decides whether to confirm a message was displayed. Receipts travel encrypted. A read confirmation is a client report, not provable proof of a person's attention.
Cryptographic state updates are guarded against stale writes.
Ratchet operations and saved state are coordinated so advancing keys aren't overwritten by stale snapshots. A transfer is a point-in-time move, not continuous multi-device use.
Your messaging identity is the Vardum ID and nickname you choose to share.
Identity introductions travel inside the encrypted conversation. Contacts never see your sign-in details. Copies a contact already holds stay under their control.
A media message that burns has its encrypted file deleted from the relay, not only its envelope.
When an opened media message reaches its burn window, the stored encrypted file is deleted from relay storage with the message record. Unreferenced media files are purged after 49 hours. Copies a recipient saved remain outside the app's control.
Contacts can be added by Vardum QR or Vardum ID.
Every Vardum ID has a QR code that can be scanned in the app or sent as a picture. The code carries only the public Vardum ID. The camera is used only while you scan, and nothing is recorded or saved. A QR code identifies an account, not a real-world person: compare the safety code to verify.
Groups
Group conversations are end-to-end encrypted for up to 100 members.
Groups use post-quantum sender keys and signed membership; the 100 includes the creator. Invites travel inside the encrypted chat with each person and only work for them. The relay sees group routing, public identity keys and membership records, not readable content.
Groups use post-quantum sender keys and per-sender signatures.
Sender signatures are checked against attested public identity keys. Group keys rotate manually at the creator's choice, plus automatically at 100 messages or every 24 hours; joining or removal doesn't itself trigger rotation. A removed member may keep earlier keys and anything already received.
Vaults
Vault contents are encrypted before upload.
AES-GCM-256 protects containers with passphrase-derived keys. PBKDF2 parameters are recorded with the container; PBKDF2 isn't memory-hard, so passphrase strength matters.
Vault passphrases never leave the phone.
Key derivation and decryption happen locally. The server holds encrypted containers, sizes and storage metadata. A lost vault passphrase can't be recovered by anyone.
Optional hidden volumes support deniability against casual inspection.
A second encrypted slot can sit inside a fixed-size container. Resistance to statistical analysis is not claimed. Container size and access timing remain visible.
Vault payloads carry no readable filenames or contents.
Encrypted container data is separate from the vault record's label, size and timestamps. We don't claim that all storage metadata is encrypted.
Notes
Private notes are encrypted before they leave the phone.
Notes use AES-GCM-256 with a key derived from your 24 words. The relay stores ciphertext, size and a nonce. Anyone holding the words can derive the notes key; the operator can't recover lost words.
Notes are gated behind your app password.
Opening the Notes tab asks for your app password every time, on top of the app lock. The notes stay encrypted with the phrase-derived key either way. The gate protects against someone handling an unlocked phone, not against extraction from a phone where the words are also available.
Identity
No phone number. No email.
You tap Create a new identity: there's no sign-up form. The app makes a random-looking sign-in label and a hidden password from your 24 words, on your phone, so nothing that belongs to you is tied to your Vardum ID. Accounts created before October 2026 may have a self-chosen sign-in address, never verified or contacted, and can switch to 24-word sign-in in Settings. The sign-in label remains account data; it isn't described as encrypted or metadata-free.
Your 24 words are the only identity recovery path.
They re-create your identity keys and the same Vardum ID on a new phone. They're not a backup of erased ratchet states, expired messages or local history. Vaults keep their own passphrases. An encrypted transfer can move still-live state while the old phone is available.
Pinned contacts warn when an identity key changes.
Pins live on the phone. A changed key prompts a fresh comparison instead of silently replacing trust. This is cryptographic identity verification, not verified contact information.
The 24 words are made on the phone and never stored.
256 bits from the iPhone's secure random generator become 24 BIP39 words with a checksum. They're shown once and never saved by Vardum or sent anywhere; the phone keeps only the keys made from them. The written copy is the one to protect.
Steganography
Text can be hidden in PNG images on the phone.
Embedding and extraction happen locally. Statistical detectability remains an explicit limit; this isn't a promise of undetectable communication.
The phone and access
The app is locked with a password, with optional Face ID or Touch ID.
A password of any characters, 4 to 50, checked on the phone, with a lockout that grows after wrong attempts (5, 10, 20, 40 and 60 minutes). Vardum locks after 1 minute of inactivity. An app lock isn't full-device encryption.
Screen capture is deterred, not guaranteed to be prevented.
Privacy shielding reduces casual exposure. Operating-system capture, external cameras, malware and copies a recipient makes remain outside the app's control.
App, decoy and duress passwords give distinct protections.
The decoy opens an empty interface; duress destroys local keys and starts deleting your relay records: identity records, sessions, vaults and notes. Your account itself survives, and your 24 words restore your identity. Server cleanup needs a network connection and is best-effort while offline. No code can erase copies someone already exported or operating-system artefacts.
An optional self-destruct countdown wipes local state after its deadline.
A fixed 14-day countdown, enforced the next time the app runs after the deadline, with a warning 12 hours before and an option to extend. It's separate from message lifetime. Remote cleanup depends on network access; operating-system remnants are outside the app's control.
Signing out wipes this phone's saved Vardum state.
Identity keys, ratchet state, cached messages and pins are removed. Your 24 words restore your identity, not wiped history. Flash wear-levelling and operating-system backups prevent a byte-level erasure guarantee.
Sign-up needs nothing that identifies you, and takes one step.
No phone number, email, one-time code or two-factor contact verification. The sign-in label is made from your 24 words on your phone. It remains account data, not encrypted content.
Product diagnostics are separate from message content.
Operational events and counts don't contain readable conversations or secret keys. Relay request metadata is disclosed separately in the privacy policy.
The double ratchet provides forward secrecy for conversations.
Used message keys are discarded. Compromising a live phone can still expose its current state and anything readable there. Group secrecy is per epoch, not the same guarantee as a one-to-one per-message ratchet.
Hybrid post-quantum key agreement continues as the ratchet advances.
Classical ECDH P-256 and ML-KEM-768 secrets are mixed into key derivation, using standard primitives in Vardum's own construction. Self-reviewed; an independent audit is planned for early 2027.
An encrypted, one-time transfer moves live state to a new phone.
The transfer expires after 10 minutes and works once. Its decryption key is carried in the part of the link that's never sent to a server; treat the link as a secret.
Calls across networks, relayed through our own server.
Tested in October 2026 between two of our own phones, one on Wi-Fi and one on mobile data. Every call is forced through a call server Vardum owns and runs, with no third-party call service, so neither phone learns the other's IP address. The audio stays encrypted between the two phones (DTLS-SRTP); the server relays packets it can't decrypt. It does see each phone's IP address while a call runs, and that a call is happening, when and for how long. Not yet in a released build: released builds call on the same network only.
An incoming call rings on the lock screen, and a missed call leaves a trace for both sides.
The lock-screen alert says only "Incoming call": no caller, no thread, no content. Same-network calling only in this build.
Relay and access
Expired ciphertext and dead sessions are swept every two minutes.
The relay removes expired envelopes, lapsed invitations and expired sessions, on top of read-time discard. Expiry and physical removal are separate: ciphertext can remain until the next sweep.
Relay writes need a live session and its write credential.
Per-session checks and rate limits protect message submission. Knowing a public Vardum ID doesn't grant its keys or another conversation's write access.
Ending a one-to-one thread removes its relay records.
The other person's unmodified app clears the thread at its next sync. A phone that stays offline, a modified app, or someone who already copied content can't be assumed to have erased it.
Envelope sender tags are rotating pseudonyms.
Message fields avoid a stable sender identity across ratchet steps. Routing records and timing remain observable; this isn't a no-metadata or no-logs claim.
Private records are protected by ownership and capability checks.
Vaults, notes, sessions and identities each have their own access checks. Encrypted content is protected by keys on the phone, separately from those checks.
The relay is self-owned and self-operated.
Vardum owns and runs its relay server. It stores and routes ciphertext; content keys stay on phones. Routing metadata, the sign-in label and network activity remain separate from encrypted content.
Deletion on the relay is checked by direct inspection.
During the October 2026 test battery, the relay's database and file store were inspected directly against live traffic: deleted records were gone and nothing survived the sweep. The claim covers what that inspection covered, the running relay, not copies on phones or provider backups.
Rate limits bound message submission.
Session-level checks limit volume. These are abuse controls, not cryptographic guarantees or a promise of uninterrupted delivery.
IP addresses are stored only as a daily one-way code.
The relay turns each connecting address into a keyed one-way code whose key changes every day and is deleted within 48 hours, and rate-limit rows expire within 24 hours. The address is still visible as each request arrives.
The Founding Tester Forum uses a 30-day message tier.
The forum's 30-day lifetime is separate from ordinary chats' 12 to 48-hour unopened settings. Groups support up to 100 members.
Open source
The app's source code is public under AGPL-3.0.
Published at github.com/VeilPrivate/VEIL. Public code lets anyone check the design; it isn't the same as an independent audit, and a published repository can lag the newest build.
Adversary tooling
Phone privacy controls reduce what a seized phone exposes.
Encrypted local storage, hardware-backed keys, Nothing at rest and hold-until-unlock reduce what a seized phone holds. They're not a guarantee against mobile extraction tools, a compromised operating system or live-memory access.
Not claimed
Resistance to statistical steganalysis.
Hidden volumes and image embedding may be detected by advanced statistical analysis.
Trace-free operation on the phone.
Operating-system artefacts, backups, live memory, network logs, external cameras and copies recipients make remain outside complete app control.
Network invisibility or metadata-free operation.
No real contact method is needed, but service use, IP addresses, request timing, sizes, public routing material and the sign-in label can still be observed.
Unbreakable or unconditionally secure encryption.
Security depends on the standard primitives, their implementation, key handling and the safety of the phones involved.
Completed independent security assurance.
The cryptography is self-reviewed. An independent cryptographic audit is planned for early 2027; this entry changes when its report is published.
Internet calling as a released feature.
Released builds call on the same network only. Calling across networks is being verified; see CALL-01.