aWallet Next Security

How aWallet Next protects your data

This page explains how the new data.crypt2 format protects your data, why it is designed the way it is, and how it compares to the original aWallet format. There is no security by obscurity here: the exact byte layout is on the file format page, precise enough to re-implement.

Design goals

1. Zero-knowledge. All keys derive from your master password, on your device. No account, no server-side key escrow, no recovery backdoor.

2. Current best practice, no inventions. Every primitive is a modern, widely audited standard from libsodium, the same library on iOS and Android, so the encrypted file is byte-for-byte compatible across platforms.

3. Fail loudly. Authenticated encryption everywhere: a wrong password or a tampered file is detected, never silently decrypted into garbage.

The key hierarchy

Your master password never encrypts data directly:

1. A password key is derived from your master password with Argon2id, the winner of the Password Hashing Competition, using a random salt and deliberately expensive parameters: 3 passes over 64 MiB of memory. Memory-hardness is the point: cracking rigs that chew through billions of fast hashes per second hit a wall when every guess needs 64 MiB of RAM.

2. A data key, 256 random bits generated once, does the actual encryption of your vault. It is itself encrypted ("wrapped") by the password key and stored in the file header.

3. An optional Recovery Key wraps the same data key a second time, so it can open the vault if the master password is lost.

This is envelope encryption, the same architecture used by modern password managers and cloud key-management systems.

Why changing your password is instant, and why that is safe

When you change your master password, aWallet derives a new password key and re-wraps only the 32-byte data key. The encrypted vault and every encrypted attachment, potentially hundreds of megabytes, are not touched and not re-uploaded.

• Atomic and crash-safe. Re-encrypting a whole vault plus attachments is a long, interruptible operation; re-wrapping one small key is a single write.

• Sync-friendly. Your cloud only receives the small vault file again.

• No security loss  against a stolen file. Without your password, nobody can open the file, before or after the change. One honest limit: the data key itself stays the same. Someone who had both a copy of your file and your old password could have taken that key, and could read newer copies of the file too, if they can still get them. So if you change your password because someone may know it, also change your cloud account's password. For a completely clean slate, export your data and start a new vault.

Attachments take the same idea one level further: each attachment is encrypted with its own random key, and those keys are stored inside the encrypted vault. So attachments inherit the vault's protection, sync as independent files and never need re-encryption.

Authenticated encryption

Every encrypted object, the wrapped keys, the vault payload and every attachment, is sealed with XChaCha20-Poly1305: a 24-byte random nonce and a 16-byte authentication tag. Encryption alone hides data; the tag proves it has not been modified. If a single bit of the file is flipped, by corruption, a sync bug or someone with access to your cloud account, decryption fails with an explicit error instead of producing subtly wrong data. The same mechanism cleanly distinguishes "wrong password" from "damaged file".

Passkeys, 2FA codes and breach checks

• Passkeys are standard WebAuthn credentials (P-256) stored inside the encrypted vault. Storing them in the vault, rather than in the phone's hardware chip which cannot export keys, is what makes them syncable and portable between iOS and Android.

• 2FA codes follow RFC 6238 and are computed entirely offline from the secret in your vault. No network, no third-party authenticator service.

• Breach checks use Have I Been Pwned's k-anonymity API: the device sends the first five characters of the password's SHA-1 hash, a bucket shared by many thousands of passwords, and compares the returned list locally. Results are cached in a local encrypted file, never in the vault, never synced.

Defense in depth on the device

• The vault, attachments and caches are additionally protected by the operating system's file encryption at rest.

• The master password and keys are held in memory only while unlocked and wiped on lock.

• Biometric unlock, idle auto-lock, optional lock in background, optional erase after failed attempts (typed attempts only; biometric failures never count).

• Privacy cover in the app switcher and during screen recording or mirroring.

How does this compare to the original aWallet?

Is the original aWallet still safe to use? Yes. AES-256 remains unbroken, and an encrypted data.crypt protected by a strong master password is not practically attackable today. Nothing about the new app means your old vault is exposed.

The honest difference is margin. The old key derivation (1000 SHA-256 iterations) is fast on the attacker's hardware too, so the entire burden rests on your password's strength. Argon2id makes each guess cost real memory and time, multiplying the attacker's cost by orders of magnitude for the same password. Likewise, the old "TRUE" marker and CRC-32 catch a wrong password and accidental corruption, but not reliably a deliberate change, while Poly1305 detects every change. The old design was reasonable practice when it shipped; the new design is what current best practice looks like, which is exactly why we built a new format instead of patching the old one.

If you keep using the original app: use a long master password, a passphrase of several words, and it remains a solid place for your data.

What we never do

• No plaintext vault, password or attachment ever leaves your device.

• No analytics or telemetry on your data; nothing readable is uploaded to us or any cloud provider.

• The optional Apple or Google sign-in exists only to link a subscription across platforms. It never sees vault data.

• No proprietary secrets in the format. The file format page documents every byte.