Security Reviews & Status

• Sessions start with an X3DH handshake over X25519 and continue with the Double Ratchet.
• Messages are encrypted with XChaCha20-Poly1305 under a fresh random 24-byte nonce from the OS CSPRNG.
• Keys are derived with HKDF-SHA256 (X3DH output and root chain) and HMAC-SHA256 (message chains).
• The initiator accepts a peer’s signed prekey only with a valid Ed25519 signature that binds it to the peer’s Veil ID.

Identity checks on the responding side and authentication of ratchet header metadata are being strengthened (section 4).

• Group chats use MLS (RFC 9420) via OpenMLS 0.8 with the MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 ciphersuite.
• The group key advances whenever membership changes.

Group chats are newer than one-to-one chats. Binding of group members to their Veil IDs and protection of group control messages are being hardened, and automatic periodic key updates are not scheduled yet.

• In one-to-one and group chats, files are encrypted with AES-256-GCM in STREAM mode (64 KiB chunks).
• Each file gets a random key and nonce from the OS CSPRNG; every chunk’s authentication tag is checked on decryption.

Attachments posted to public channels are not encrypted. Protection of thumbnails and re-sent files is being hardened.

• The local database is encrypted with SQLCipher under a random 256-bit key.
• The key is stored in the iOS Keychain (this device only, available after first unlock) or in Android Keystore-protected storage.
• New attachments are stored encrypted on disk under a per-chat storage key.

The Secure Enclave only supports NIST P-256 keys, so the Ed25519 and X25519 keys VeilMesh uses cannot live inside it; they are kept in the iOS Keychain, whose items are protected by a hardware-bound device key, and items marked this-device-only are not restored to other devices from a backup. Cleanup of some temporary media files and further key-handling hardening are in progress.

• Every mesh packet carries an Ed25519 signature and a small fixed proof-of-work that is checked before the signature. The proof-of-work is a cheap pre-filter, not an anti-spam control.
• Protocol V2 obfuscates the sender key and packet ID in each header with ChaCha20 under a fresh random 12-byte nonce, so these fields do not appear as plain bytes in a raw capture.

Header obfuscation uses a key built into the app, so it only hides these fields from casual capture; it is not anonymity. Devices that relay a mesh message can read the sender’s Veil ID and the chat identifier in its envelope — the message text stays end-to-end encrypted. V1 packets from older builds are still accepted on receive.

• Call setup messages (SDP offers and answers, and ICE candidates, which contain IP addresses) are end-to-end encrypted before they reach any transport.
• Call signaling that arrives unencrypted is refused.

• Ghost Mode keeps message delivery on the local mesh (Bluetooth and local Wi-Fi) and stops the app from sending through the relay — for conversations you do not want our relay to route at all.

Nearby devices that relay your messages still see the envelope metadata described under Mesh Packets.

• Mesh delivery and read acknowledgements carry an HMAC-blinded message identifier and a short random delay, so an acknowledgement does not reveal which message it confirms.

This covers the message identifier only and is not a general defense against traffic analysis.

• The relay forwards end-to-end encrypted payloads it cannot decrypt and holds no end-to-end private keys.
• Database queries use sqlx with bound parameters; SQL text is not built from user input.
• Account registration and public channel endpoints (directory, post history, attachment downloads) are rate-limited per client IP.

The relay does see routing metadata — sender and recipient identifiers, connection times and addresses — and some signals that are not yet end-to-end encrypted, such as typing indicators, read receipts and group names set at creation.

• Keys and nonces come from the operating-system CSPRNG (OsRng).
• Identity keys and Double Ratchet state are zeroized when released; X3DH intermediate secrets are wiped right after use.
• Log statements are reviewed so that private keys, seeds, ratchet state and session tokens are not written to logs.

Some short-lived copies, such as serialized session state and per-message keys, are not wiped yet.

• The gateway’s TCP backhaul requires mutual TLS (tokio-rustls, client certificates checked against an operator-provided CA) and refuses to start without certificates unless an explicit insecure test flag is set.
• WisBlock firmware takes packet nonces and IDs from the nRF52840 hardware RNG and reads a per-device Ed25519 key from UICR memory when one is provisioned.

The LoRa radio link is outside the TLS layer, and WisBlock telemetry payloads are signed but not encrypted.