Understanding Argon2id & AES-256-GCM Encryption

Open any password manager's security page and you'll hit a wall of acronyms: AES-256, Argon2id, PBKDF2, GCM. They sound interchangeable, but two of them are doing very different jobs, and getting both right is the difference between a vault that shrugs off a leaked backup and one that doesn't. Here's the short version, no cryptography degree required.

The two jobs your vault has to do

Protecting your data really comes down to two steps. First, turn the password you can remember into a proper encryption key. Second, use that key to scramble your data so nobody can read it or quietly change it. Argon2id handles the first step. AES-256-GCM handles the second. Let's take them one at a time.

Step one: Argon2id turns your password into a key

Your master password isn't the encryption key itself. It's too short and too human for that. The app has to stretch it into a full 256-bit key first, and how it does that stretching matters enormously.

Old methods like a single pass of SHA-256, or a lightweight PBKDF2 setup, are fast to compute. That sounds good until you realize an attacker who steals an encrypted backup can be fast too. With a rack of graphics cards, they can test billions of password guesses every second, because each guess is cheap.

Argon2id, which won the international Password Hashing Competition, is deliberately expensive in a way that hurts attackers far more than it hurts you. It's what cryptographers call memory-hard: every single guess has to allocate a chunk of RAM to complete. In OneVault, each attempt claims 19 megabytes. Your phone does that once when you unlock, and never notices. A GPU cracking rig, though, lives or dies on running thousands of guesses in parallel, and it simply doesn't have the memory bandwidth to feed 19 MB to thousands of cores at once. The memory requirement quietly strangles the whole attack.

Step two: AES-256-GCM locks the data

Once Argon2id has produced your key, your passwords, cards and notes get encrypted with AES-256-GCM. There are two parts to that name and both earn their place.

• AES-256 is the encryption standard governments and banks have trusted for two decades. With a proper key, there's no known practical way to brute-force it.
• GCM is the part people overlook. It adds an authentication tag to every encrypted chunk, so the app can tell if anything was tampered with. Older CBC-mode encryption would happily decrypt altered data into garbage and hand it back. GCM refuses, which means a corrupted or maliciously edited backup fails loudly instead of silently poisoning your vault.

The exact settings OneVault uses, and why

"We use Argon2id" tells you almost nothing on its own. Argon2id is a family of settings, and a badly tuned configuration is barely better than the fast hashes it replaced. So here are the actual numbers from our code:

• Memory: 19,456 KiB, which is the 19 MiB figure above
• Iterations: 2 passes over that memory
• Parallelism: 1 lane
• Output: a 32-byte (256-bit) key

That combination is not arbitrary. It is exactly the minimum configuration published in the OWASP Password Storage Cheat Sheet, which lists m=19456, t=2, p=1 as one of several equivalent settings that reach the same security level. We picked that row rather than a lower-memory, higher-iteration one because memory is the axis that actually hurts GPU attackers.

There is an honest cost to this, and it shows up on the unlock screen. Our Argon2id runs in pure Dart rather than a native library, which is roughly an order of magnitude slower than a C implementation. On a current phone you barely notice. On an older budget Android device, deriving the key genuinely takes a few seconds, which is why unlocking shows a progress state instead of pretending to be instant. We would rather you wait two seconds once than have a key an attacker can guess cheaply.

The parameters are also written into every encrypted blob alongside the salt, rather than hard-coded into the reader. That sounds like a small detail and it is the reason we can raise the cost later: a future version can derive new keys at higher settings while still opening vaults created today.

Your password is not the key, and that matters

A design most people never see, but which decides how the app behaves: your master password does not encrypt your vault directly.

When you first set up, OneVault generates a 32-byte key at random. That key, the one that actually encrypts your data, never comes from your password at all. What Argon2id produces from your password is a second key whose only job is to encrypt the first one. The random key is stored on your device only in that wrapped form, and it is unwrapped into memory after you unlock.

Two useful properties fall out of that split:

• Changing your master password is instant. Nothing in your vault has to be decrypted and re-encrypted. The app derives a new wrapping key and re-wraps the same underlying key. A vault with thousands of entries changes password as fast as one with three.
• Your recovery code can survive a password change. The one-time code you get at setup wraps its own copy of that same random key, under its own separately derived key. It is not a backup of your password, so changing your password does not invalidate it.

It is also why the encrypted backup can be written without asking for your password. The wrapped key and its salt are already on the device, so a scheduled backup copies them as they are. Opening that backup on a new phone still needs the password, because unwrapping is the only way in.

What this design does not protect against

Any security page that only lists strengths is selling you something. This one has real limits, and they are worth knowing:

• A weak master password. Argon2id multiplies the cost of each guess, but it cannot rescue a password that appears in a leaked wordlist. Memory-hardness buys you orders of magnitude, not infinity.
• A compromised device. While the app is unlocked, the key is in memory by necessity. Malware with sufficient access on your phone is a different threat model than a stolen backup file, and encryption at rest does not answer it.
• Anything you have already given away. A password you typed into a phishing page is gone regardless of how the vault stores it.

What the design does answer, completely, is the case that has actually burned real people: a copy of the encrypted vault ending up somewhere it should not be. That file is unreadable without your password, and there is no server-side key that changes the answer.

What "zero-knowledge" really means here

Put the two steps together and you get the property that actually matters: at no point does a readable version of your key leave your device. Argon2id runs on your phone's own processor, in a background isolate so it never freezes the screen. The derived key exists only in memory while you're using the app. Nothing readable is written to disk, and nothing is sent to a server. That's why even we can't open your vault, and why a leaked backup is just noise to whoever finds it. It's also why there's no password reset: there's no copy of your key anywhere for us to recover.

This is the same architecture that makes browser-stored passwords look fragile by comparison, a topic we cover in why browser-saved passwords are a risk. And if you're weighing which apps get the cryptography right, the 2026 password manager comparison is a good next read.