Encryption, recovery codes, backups, device migration — the answers to what you care about, right here.
Yes, it really is. CosmosBox is designed with no accounts: data lives only on your own device by default, processed by the strongest recognized algorithms — your password is run through Argon2id (using 128MB of memory; GPU brute force is practically impossible) to derive a master key, and every file is then encrypted with its own independent AES-256-GCM random key. The key (master key) exists only in memory while you’re unlocked and is wiped the moment you lock; data keys are held by the phone’s system secure chip (Android Keystore / iOS Keychain).
No account means there is no “server holding your password” link in the chain — the password leak surface is zero. The trade-off: if you forget your password, only the recovery code can bring your data back.
That’s what “password recovery” (the recovery-code system) is for. Once enabled, the app generates a recovery code (splittable into 5 shares; any 3 restore access): keep 1-2 shares yourself and give the rest to people you trust. When you forget your password, entering the recovery code resets it and restores all data — no server involvement at all.
If you’ve forgotten your password, never enabled password recovery, and have no backup — the data cannot be recovered. That is the physical boundary of zero-account encryption, which is why we strongly recommend: enable password recovery right after setting your password.
The recovery code = a 32-byte true random number (32 × 8 = 256 bits of entropy), generated with the system’s secure random source (Random.secure()) — every bit is the result of an independent coin flip. Breaking it means finding the right one among 2²⁵⁶ possibilities.
How big is 2²⁵⁶? A few intuitive comparisons:
So “mathematically unbreakable” precisely means: not absolutely impossible, but impossible within the computing power physics allows — it’s not “hard”, it’s “physically impossible”.
Quantum computers can’t save you either: Grover’s algorithm halves symmetric key search: 256 bit → 2¹²⁸ tries. But 2¹²⁸ still exceeds the number of atoms in the universe — quantum computers are equally stuck. The recovery code’s AES-256-GCM is precisely the strength level that resists quantum search.
Why are human passwords different?
| Human password | Recovery code | |
|---|---|---|
| Entropy source | Your memory — predictable (common words, birthdays, keyboard patterns) | True random number generator |
| Actual entropy | 12 random characters ≈ 78 bit; common passwords often < 30 bit | 256 bit |
| Cracking cost | 30 bit ≈ 10⁹ attempts, a few hours on a GPU | 2²⁵⁶ attempts, physically impossible |
The gap between 30 bit and 256 bit is not 8× but 2²²⁶ ≈ 10⁶⁸× — that’s why “a strong KDF (Argon2id) protects human passwords, but is only icing on a 256-bit random key”: the recovery code doesn’t need KDF slowing at all — it is already a full-entropy key.
The honest boundary: “mathematically unbreakable” protects only the key itself. What actually defeats a recovery code is never brute force, but the human link — a paper copy photographed, a phone note with a rooted device, a screenshot sent to yourself in the cloud. A key, no matter how strong, is worthless once leaked. Iron rules: write it on paper and lock it in a drawer / store it in a password manager (with a strong master password too) — no photos, no cloud, no sending it to anyone. Friend shares are Shamir-split fragments; a single share is useless, so sharing is safe.
Storage encryption levels (encrypted camera, encrypted notes and similar tools), from weakest to strongest:
| Level | File | Security | New device |
|---|---|---|---|
| Plain | not encrypted | anyone who gets it can read it | just copy it |
| Portable | encrypted, salt in file | requires password | enter password |
| Salt-separated (encrypted) | encrypted, salt on device | requires password + device salt | requires recovery code |
| Salt exchange (strongest export) | encrypted, salt exchanged offline | password + salt, two factors | requires the other party’s salt |
Easy memory rule: plain → portable → salt-separated, security goes up and so does friction. The default “follow global” is fine for most; the more sensitive the file, the higher the tier you pick.
Standard flow: back up on the old phone (local or WebDAV cloud) → restore on the new phone → enter the backup password.
Recovering the old keys on a new device: the backup automatically carries the recovery configuration — after restoring, enter the recovery code and the old device’s master key is restored, so all encrypted data is immediately readable.
Single-file sharing: tools like character cards support export — the portable format only needs the export password on the new device; the “offline salt exchange” format requires exchanging the salt first (more secure, ideal for sensitive files).
Because a backup is not a plain copy of ciphertext. A backup must let you rebuild everything on a new device, so the package contains not only ciphertext but also plaintext structural data (some tool data) and key material (salt, checksums, recovery configuration) — all of which must be locked again as a whole with the backup’s own password. On-device encryption defends against “file leaks”; the backup password defends against “backup file leaks” — two independent layers. Forgot the backup password? You’d need the recovery code to restore the master key and then back up again.
Encrypted backups are uploaded automatically to your own cloud drive / private cloud (Jianguoyun, NextCloud, Synology or any WebDAV server) — no third party in the middle. Backup files are encrypted (.encbak), the password lives in the Keystore, and transfers run over HTTPS. Daily/weekly automatic backups run on schedule at startup — even a lost device can be recovered from the cloud.
Salt lost: a salt-separated backup (the file carries no salt) can no longer be decrypted — not even by you. That’s why enabling salt separation triggers repeated reminders: export the backup salt and keep it offline (USB drive / printout / password manager).
Salt leaked: every salt-separated backup created before the leak is compromised (irrecoverable — consider deleting old cloud backups); after regenerating the backup salt, new backups automatically use the new salt and are safe again. Old backups stay restorable while the old salt remains in the salt library.
If you’d rather not carry the burden of keeping a salt, the default “portable” backup is fine — it carries the salt, restores on a new device with just the password, and is already very secure.
No. An early version had a serious flaw where external file imports overwrote existing data; it was fixed in later releases: when the device already has data, opening a backup externally goes through unlock-then-merge import (existing data + new items, deduplicated by id); only a completely empty device (first use) does a one-step import. Please make sure you’re on the latest version.
If it’s a backup exported by an old version: the photos inside are still encrypted with the source device’s keys, which the target device cannot decrypt — re-export from a new version instead (new exports re-encrypt photos with the export password, so entering the password on the new device shows them).
If it’s a new-version export: make sure you entered the export password; the “offline salt exchange” format additionally requires importing the sender’s salt first.
Both historical issues are fixed: ① the share target used to merge into this app’s task stack, causing “stuck on the WeChat screen” — sharing now opens in an independent task, and returning brings you straight back; ② FileProvider crashes on Huawei devices (caused by R8 obfuscation) crashed exports — fixed by keeping org.xmlpull.v1. If you still run into problems, tell us your device model and system version via feedback.
Encrypted exports enforce a strong password: at least 8 characters, containing letters and digits, and not purely numeric or purely alphabetic — weak passwords cannot be confirmed. Because in the portable format the salt travels with the file, the password is the file’s only key — the stronger the password, the safer the file; combined with “offline salt exchange” exports, even a leaked password + file cannot be opened.