Aexa Web Vault performs post-quantum file encryption and decryption locally in your browser. Aexa servers do not receive your plaintext files, private keys, passphrases or decrypted output. A browser is a network application, so this edition does not carry the OS-enforced isolation claim of the native editions. Not approved for classified information, CUI, National Security Systems or regulated data. Verified browsers are listed at vault.aexa.com.
AEXA

Post-Quantum Vault

Your files don’t come to us.

Protect today’s information for a post-quantum future.

New here? Start with : it creates your private key file and the public key file you give to others.

Encryption and decryption happen locally in your browser. Your file never leaves your device.

Files, keys and identities are the same across the Web Vault and the native macOS and Windows applications: a file protected in one unlocks in the others.

What just happened?

AES-256

Protects the actual contents of the file.

ML-KEM-768 and ML-KEM-1024

The NIST-standardized lattice-based post-quantum key-establishment mechanism (FIPS 203) used to protect the file encryption key. It is designed to resist attacks from both classical and future quantum computers. ML-KEM-768 is security category 3 and is the Standard profile; ML-KEM-1024 is security category 5 and is the High Assurance profile. They are two parameter sets of the same standard: the High Assurance Cryptographic Profile is the higher-security parameter set, not a different kind of protection.

Your key file

The .aexkey file this Web Vault writes is the same version 2 format the native macOS and Windows applications write: the whole header is authenticated, and the key inside is protected with a passphrase using Argon2id at one fixed, approved cost. Older version 1 key files from the earlier browser build still unlock here; they cannot be created any more.

Local encryption

The file is processed in your browser. Aexa does not receive the plaintext file. This page is served with a Content-Security-Policy that denies every fetch, socket and resource channel after it has loaded, and the application removes WebRTC — the one channel no browser's policy can deny — from itself. Encryption and decryption keep working with your network disconnected — you can try it.

What the Web Vault does not do

It does not tell you who sent a file. A protected file proves only that someone who had your public key created it. It does not have the native applications’ isolation property: a browser tab cannot refuse to be a network application, whereas the sandboxed native process cannot reach the network at all. Nothing here is a FIPS 140-3 validated module, and nothing here is approved for classified, CUI, NSS or regulated data.