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 -
Quantum-seeded Identity
New Your identity, seeded with random numbers measured on a quantum computer. One press.
Quantum-seeded 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.
Browser verification for this release is listed below · Aexa Web Vault 1.2.1
New: Quantum-seeded Identity
Every key begins as random numbers. Now yours can begin with numbers no formula produced.
Aexa measures random numbers on a real quantum computer, tests them, signs them, and hands them out one single-use piece at a time. Press one button and the Vault opens with a piece ready. Your device mixes it with its own fresh random numbers and builds your identity from both.
- One press. No file to handle, no account, no installation, and nothing that depends on what your browser lets a page do with files.
- Issued once, used once. The piece you receive is marked as used the moment it is issued and is never given to anyone else.
- Checked on your device. The Vault verifies Aexa’s signature on the piece and refuses anything Aexa did not issue.
- Never a weaker key. The piece is combined with your device’s own random numbers using the construction in NIST SP 800-133 Rev. 2, Section 4.4 The result is at least as unpredictable as your device’s numbers alone, even if someone else held a copy of the piece.
- A receipt you can keep. It records the machine, the job and the exact piece that went into your key.
Create a Quantum-seeded Identity
Beta. Optional, and a daily limit applies. The standard Generate Identity works exactly as before and is just as sound. How it works, in plain language.
How Aexa Web Vault Works
First, create your identity, once. Your device makes fresh random numbers and, if you choose, mixes in one quantum-sourced piece. The result is your key pair: a private key that stays with you, locked by your passphrase, and a public key you give to anyone who will send you files.
Then, protect and share files. Choose a file, load the public key of the
person who will open it, and encrypt locally in your browser. Download the protected
.aex file and send it any way you like. Only the matching private key and
its passphrase can unlock it, and that happens locally too.
Aexa Post-Quantum Vault
Your data. Your control. A more secure tomorrow.
First, create your identity once
Your Device
Fresh random numbers, made on your device. Always used.
Quantum Piece
Random numbers measured on a quantum computer. Signed by Aexa. Issued once, used once.
Mixed on Your Device
Combined in your browser, so the result is at least as strong as your device alone.
NIST SP 800-133
Your Identity
Private key Stays with you, locked by your passphrase
Public key Give it to anyone who sends you files
Your Receipt
Records what seeded your key, down to the exact quantum piece.
Then, protect and share your files
Choose File
It never leaves your browser
Load Public Key
The key of the person who will open it
Encrypt in Your Browser
ML-KEM + AES-256-GCM
Download Secure Vault
One protected .aex file
Share Securely
Send the vault any way you like
Unlock Locally
Private key and passphrase required
- Runs locally in your browser
- Aexa servers do not receive your files, private keys or passphrases
- Built for the post-quantum era
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-10-13, Chromium 141.0.7390.37 |
| Safari | Not yet verified |
| Firefox | Verified 2026-10-13, Firefox 142.0.1 |
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.2.1, commit 06dad9b6421c0f3c1ba3a128007de442e12b7e8d |
|---|---|
| Bundle manifest | AexaVault-1.2.1-webvault-manifest.json9790aa0bb73c63b94777aa942e5dcdae58d75fefd28b27951087ef79aec403d5 |
| Bundle archive | AexaVault-1.2.1-webvault.tar.gzb2c2370e844cd12a577dc7d9b8c3e0f13bfd85151591c3f11abbd47324d05e0b |
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.
Quantum-sourced key seeding, in plain language
Optional. When you generate an identity, the Web Vault can mix in random numbers that were measured on a quantum computer. Without them, the Vault works exactly as before and your identity is just as sound.
There are two ways to bring a piece of those numbers to the Vault:
- On demand, from Aexa’s entropy service (beta). One press on the quantum-seeded identity page gives you one piece and opens the Vault with it. There is no file to handle, so it does not depend on what your browser lets a page do with files. Every piece carries Aexa’s signature, and the Vault refuses a piece Aexa did not issue. A daily limit applies.
- From an entropy pool file. A file of many pieces that you keep. This works in Chromium-based desktop browsers such as Chrome and Edge, because the Vault has to erase each used piece from the file and other browsers do not let a page update a file. Pool files are not yet offered to the public.
What entropy is
Entropy is unpredictability. A key is only as strong as the random numbers it was made from: if someone could guess those numbers, they could rebuild the key without breaking any encryption. So the question behind every key is simple. How hard were its starting numbers to guess?
The Vault always takes those numbers from your device's own generator, and that generator is what protects your key. Quantum-sourced key seeding adds a second ingredient: random numbers produced ahead of time on a quantum computer. They reach you one piece at a time from Aexa’s entropy service, or many at once in a file called an entropy pool.
Where the numbers come from
- A quantum computer flips the coins. Each of its qubits is put into a state that is equally likely to be read as 0 or as 1, and then it is read. Which way each one falls is not worked out by a formula, so it cannot be calculated ahead of time.
- Aexa checks the results. The raw readings are tested. A run that fails is thrown away. What passes is condensed into single-use pieces, recorded with the machine and the job that produced them.
- Your device mixes one piece in. When you create an identity, the Vault combines one piece with your device's own random numbers, using the construction in NIST SP 800-133 Rev. 2, Section 4.4 The result is at least as unpredictable as your device's numbers alone, even if someone else had a copy of the piece. Each piece is used once and then removed.
- You receive a receipt. It names the machine, the job and the piece that was used for your key.
What an entropy pool is
An entropy pool is one file. Think of it as a booklet of tear-off tickets: each ticket is one piece of quantum-sourced random numbers, and each new identity tears off exactly one.
- One piece per identity. A piece is 64 bytes, which is 512 random bits. Creating an identity uses one piece. Encrypting and decrypting files uses none.
- Single use. Once a piece has been used it is erased from the file and can never be used again, by you or by anyone else. No piece is ever placed in two pools.
- It runs out. A pool holds a fixed number of pieces and the Vault shows how many are left. When they are gone, that pool is finished.
- It stays with you. You load the pool from your own device. The Vault reads it locally and does not upload it.
- It is labeled. The file records which machine produced it, in which job, and when. Your receipt carries the same details, so a key can be traced back to the run its piece came from.
- It fails safe. If a pool is damaged, empty, or made from test data, the Vault stops and tells you. It does not quietly make a key without the piece you asked for.
Common questions
- How do I get a quantum-seeded identity? Open the quantum-seeded identity page and press the button. The Vault opens with one piece ready. Choose your passphrase and generate.
- Why would I want one? A second, independent source of unpredictability costs you nothing in strength and gives you a record of where part of your key’s starting numbers came from. If your device’s generator were ever weaker than it should be, an attacker without a copy of the piece would have to guess the piece too.
- What does the service learn about me? Nothing about your files, keys or passphrase. To enforce the daily limit it keeps a keyed hash of your network address for up to three days, not the address itself.
- Does the quantum computer encrypt my files? No. It never sees them. Your files are protected by ML-KEM and AES-256-GCM exactly as described above, on your own device.
- What if someone else has a copy of my pool? Whoever produces a pool could keep a copy, and a file can be copied in transit. That is why a piece is never used alone. It is always combined with your device's own random numbers, so a person holding a copy of the piece would still have to guess your device's numbers.
- Is my key weaker without a piece? No. Your device's generator protects your key today and continues to. The quantum-sourced numbers are a supplement to it, not a replacement for it.
- Do I need a pool to open a file someone sent me? No. A pool is used only at the moment an identity is created. After that, the pool plays no part.
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 quantum encryption, and no certified quantum randomness. The quantum-sourced key seeding described above adds a second source of randomness to key creation and nothing else. It is not quantum key distribution, it is not an approved or validated entropy source, and whoever produces the quantum-sourced numbers could keep a copy, which is why your device's own generator remains what protects your key. A piece from the entropy service is signed by Aexa: the signature shows who issued it, not how it was made. The machine and job named in a receipt come from the piece or the pool file, and the receipt itself is not signed.
- 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
- NIST SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation, June 2020. https://csrc.nist.gov/pubs/sp/800/133/r2/final
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.