Skip to main content

Security Overview

AliasVault is a password and email alias manager with end-to-end encryption: your vaults and the emails your aliases receive are encrypted with keys that only exist on your devices, and the server stores ciphertext it cannot read. This page is the short version. The complete design, the threat model and more can be found in the Security Whitepaper.

AliasVault Security Architecture DiagramAliasVault Security Architecture Diagram

How it is secured​

  1. Your master password never leaves your device. Argon2id derives your keys from it on the device, and the SRP protocol proves it to the server without sending it. Whitepaper§4 Key derivation →§5 Authentication →
  2. One key hierarchy, created on your device. The master password unlocks your Account Key, which opens a separate key for every vault and every attachment. The server stores each of these keys only in encrypted form. Whitepaper§4.1 Key hierarchy →
  3. Vaults are encrypted before they are uploaded. Every vault is encrypted with AES-256-GCM and bound to its own id, so the server cannot read it, change it, or swap it for another vault's data. Whitepaper§6 Vault operations →
  4. Emails are encrypted the moment they arrive. Each incoming email is encrypted in memory with the public key of the vault its alias belongs to, before it is stored. Only members of that vault hold the private key. Whitepaper§7 Email →
  5. Passkeys live in your vault. AliasVault is the authenticator: it creates each passkey on your device, and the private key never leaves it. Whitepaper§8 Passkeys →
  6. Login with Mobile moves your key, not your password. The new device creates a one-time keypair, your phone encrypts the Account Key for it, and the server relays ciphertext it cannot open. Whitepaper§9 Login with Mobile →
  7. Shared vaults have their own key. The key is encrypted for each member separately; membership of a group by itself opens nothing, and your personal vault is never shared. Whitepaper§10 Vault sharing →
  8. On your device, the vault stays encrypted at rest. Biometrics, a PIN or a passkey unlock a device-only copy of your Account Key; locking removes the keys from memory. Whitepaper§11 Keys on the device →
  9. Exports are encrypted too. The .avex export is encrypted under a key derived with Argon2id from an export password of your choice. Whitepaper§12 Vault exports →
  10. One cryptographic core for every app. The cryptography runs in a shared Rust core that every client embeds. Whitepaper§3 Algorithms →

What the server cannot do​

  • The server cannot read your vaults or your emails.
  • The server cannot learn your master password or any of your keys.
  • The server cannot change what is in a vault, or move data between vaults or users.
  • The server cannot give anyone access to a vault: only a holder of the vault key can grant access, and every grant is signed.

What the server does store in plaintext, and what an operator can do with it, is listed in the whitepaper: What the server knows and can do.

Assumptions and limits​

These protections assume you use a device you trust, the official AliasVault apps and a strong master password. Malware on your device can see everything you can see. The full list of assumptions is in Trust assumptions, and the adversaries the design is built against are in Threat actors.

Open source and disclosure​

The server, every client and the Rust core are open source under AGPL-3.0 in one repository, and the same apps are used with AliasVault Cloud and with self-hosted servers. To report a vulnerability, see Audits and Disclosure.

Where to go next​