Back to Blog
Security Architecture October 2026 6 min read

How VeilMesh Stores Keys and Chats on Your Devices

Why Ed25519 and X25519 keys cannot be stored in the Secure Enclave, which supports only P-256, and how VeilMesh protects keys and chat databases at rest with Keychain/Keystore, SQLCipher, an Argon2id app lock and Mirror Phone, which writes nothing to disk.

End-to-end encryption does not help if an attacker or a forensic tool can read the message database or pull the keys from a cloud backup.

Below is how VeilMesh creates, stores and erases keys on iOS, Android and desktop, why Ed25519 and X25519 keys cannot be kept in Apple's Secure Enclave, and what we do instead.

VeilMesh Core Cryptographic Key Storage
Figure 1: Key generation in the Rust core paired with hardware-backed OS Keychain/Keystore protection, SQLCipher, and Argon2id App Lock.

1. Why Ed25519 & X25519 Cannot Live Inside the Apple Secure Enclave

Some messaging apps claim that their Ed25519 or X25519 keys are generated and used strictly inside the Apple Secure Enclave coprocessor. They cannot be. Apple's Secure Enclave supports only the NIST P-256 curve, not Curve25519.

Because VeilMesh uses Ed25519 for identity signatures and X25519 for X3DH, Double Ratchet, and MLS key agreements across all platforms, our keys are generated in software inside veilmesh-core using the operating system's cryptographically secure random number generator (OsRng) and zeroized from memory when released.

2. Hardware-Backed Keychain & Keystore Protection at Rest

VeilMesh keeps your identity seed and the 256-bit database key in the system's hardware-backed key store, not in files:

  • iOS Keychain (kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly): Keys are encrypted by iOS using keys tied to the device's hardware UID and are marked ThisDeviceOnly, so they are not synced to iCloud Keychain and are not restored to another device from a Finder backup.
  • Android Keystore (AES-256-GCM): Keys are wrapped under an AES-256-GCM master key managed by the Android Keystore (backed by TEE or StrongBox hardware on supported devices).

3. SQLCipher Database, Argon2id App Lock & Duress Wipe

All local message history, contact lists, and ratchet states live inside a SQLCipher database encrypted under a random 256-bit key, while media attachments are encrypted on disk under per-chat keys. There are two more protections you can turn on:

  • Argon2id App Lock: You can lock the app and sensitive Locked Chats behind a PIN or passphrase stretched with memory-hard Argon2id.
  • Duress PIN (Coercion Wipe): If forced to unlock your phone under duress, entering your configured Duress PIN erases your identity keys and chats on the device; this cannot be undone.

4. Mirror Phone on desktop

Computers are harder to protect at rest than phones. Besides a normal account, the desktop app has a Mirror Phone mode, which writes no account keys or chat history to your computer's disk. All mirrored state lives only in RAM, is wiped with zeroize as soon as you disconnect or lock your screen, and travels between your phone and computer over a hybrid post-quantum channel (a Noise handshake over X25519 combined with ML-KEM-768).