Aexa Web Vault
-
Protect a File
Encrypt a file for someone's public key. The file never leaves your browser.
Protect a File -
Unlock a File
Open a protected
Unlock a File.aexfile with your private key and passphrase. -
Generate Identity
Create your private key file and the public key file you give to others.
Generate Identity
The application runs at https://webvault.aexa.com/, its own strict origin,
separate from this page. No installation, no account, no upload. After it has loaded it makes
no network request, and it works with the network disconnected.
Verified browsers are listed below · Aexa Web Vault 1.0.0
Cryptographic profiles
| Profile | Key establishment | Content encryption |
|---|---|---|
| Standard (default) | ML-KEM-768 — NIST FIPS 203, security category 3 | AES-256-GCM |
| High Assurance Cryptographic Profile | ML-KEM-1024 — NIST FIPS 203, security category 5 | AES-256-GCM |
Both profiles use the same standardized algorithm. The High Assurance Cryptographic Profile is the higher-security parameter set of that standard; it names the cryptography only and says nothing about the browser. Your private key file is protected with a passphrase using Argon2id. Files, keys and identities are one format across editions: a file protected in the Web Vault can be unlocked by the native editions, and the reverse.
Verified browsers
Support is claimed only for browsers on which the full workflow has actually been run against the production origin. The rows below are updated only from a recorded run.
| Browser | Status |
|---|---|
| Chromium-based (Chrome, Edge) | Verified 2026-09-05, Chromium 141.0.7390.37, 14 of 14 tests passed on the production origin |
| Safari | Not yet verified |
| Firefox | Not yet verified |
Verify what you are running
The Web Vault is a fixed set of files with no build step, no bundler and no third-party code. Every file's SHA-256 is recorded in a bundle manifest before publication, and the manifest's own hash is published here and in HASHES.txt.
| Release | 1.0.0, commit 7c31ae1d72491d52d9d5fee0dd779395bf58b340 |
|---|---|
| Bundle manifest | AexaVault-1.0.0-webvault-manifest.jsonce001f0b09d22981fe4e95044d930f498490d35557c082a92d45c4603b11d68b |
| Bundle archive | AexaVault-1.0.0-webvault.tar.gz3bec4619834f4cfa1d2a9c21cfdf3ba7738118efc035a451fe230826c16728c7 |
Anyone can rebuild the bundle from the source repository at that commit and compare. Every file the application origin serves is listed in the manifest; the origin refuses everything else, sets no cookies, and sends a Content-Security-Policy that denies every fetch, socket and resource channel. WebRTC, the one channel no browser's policy can deny, is removed by the application from its own page.
Phase 2: native editions
Aexa Vault Native for macOS and Aexa Vault Native for Windows are in development for customers who need a stronger, operating-system-enforced boundary: the process that handles your files has no network capability at all. They read and write the same files as the Web Vault. They are not yet available for download.
What we don't claim
- The Web Vault does not have an operating-system isolation boundary. Its protection is that the code runs locally, makes no network request after loading, and is served under a Content-Security-Policy that denies connections. A browser tab cannot refuse to be a network application; a sandboxed native process can. That is the difference between this edition and the native editions, and we state it rather than blur it.
- Delivery cannot be verified by the page itself. Every visit downloads the application from Aexa's server. The published hashes make a substituted bundle detectable; they do not make it impossible.
- No FIPS 140-3 validation. FIPS 203 standardizes the algorithm. Validation is a property of a specific module, issued by the CMVP as a numbered certificate, and Aexa Vault holds no such certificate.
- Not approved for CUI, classified information, National Security Systems or regulated data. No government body has certified or approved this product.
- No sender authentication. A protected file proves only that someone who had your public key created it.
- No guarantee of perpetual secrecy. The design goal is resistance to known classical and quantum attacks.
Designed for the Post-Quantum Era
Aexa Post-Quantum Vault is designed around cryptographic algorithms selected for a world in which large-scale quantum computers may eventually threaten many of today's public-key encryption systems.
The Vault uses ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism standardized by the U.S. National Institute of Standards and Technology in FIPS 203. NIST states that the security of ML-KEM is related to the computational difficulty of the Module Learning with Errors problem and that ML-KEM is currently believed to be secure even against adversaries possessing a quantum computer.1
Aexa Vault provides ML-KEM-768 as its Standard profile and ML-KEM-1024 as its High Assurance profile. File payloads are protected using AES-256-GCM. NIST suggests AES-256-GCM with a random IV for authenticated encryption and states that AES-192 and AES-256 are expected to remain safe for a very long time against known quantum brute-force techniques, assuming no new cryptographic weaknesses are discovered.3
No cryptographic system can guarantee security against all future discoveries. Post-quantum cryptography is intended to address currently understood quantum threats using algorithms that have undergone extensive public analysis and standardization.2
References
- NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 13, 2024. https://csrc.nist.gov/pubs/fips/203/final
- NIST, Post-Quantum Cryptography Standards, including FIPS 203 / ML-KEM. https://csrc.nist.gov/projects/post-quantum-cryptography
- NIST, Post-Quantum Cryptography FAQ, including guidance regarding AES-256-GCM and symmetric cryptography in the quantum era. https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs
Beta Notice and Disclaimer
Aexa Post-Quantum Vault is currently offered as beta software for evaluation and testing. Cryptographic security depends on implementation, operating environment, key and passphrase protection, software integrity, and future cryptanalytic developments. No cryptographic technology can guarantee protection against every present or future attack. Use of algorithms standardized in NIST FIPS 203 does not mean that Aexa Post-Quantum Vault itself is FIPS 140-3 validated, certified, endorsed or approved by NIST or any other U.S. Government agency. Aexa does not claim that this beta is approved for classified information, National Security Systems, CUI, or other regulated workloads unless separately authorized and validated for the applicable environment. Users are responsible for maintaining secure backups of keys and encrypted data. Aexa makes no representation that beta software is error-free or suitable for any particular regulated use.