Encryption & export compliance

What a key manager owes you is not a promise of safety but a plain account of what it does: which published algorithms, where the key lives, and whether we could read your data (we cannot). This page is that account. It is kept in step with the code and reproduced inside the app.

Algorithms in use

  • AES-256-GCM

    Encrypts secret values, notes, rotation history and the trash in the local database; wraps the data key under the optional master password and recovery phrase; seals a backup file when you give it a password.

    Apple CryptoKit

  • PBKDF2-HMAC-SHA256, 600,000 iterations

    Turns the optional master password into the key that wraps the data key, and a backup password into the key that seals a backup file. Deliberately slow — a few seconds — because it runs only when you type a password.

    Apple CommonCrypto

  • HKDF-SHA256

    Turns the 128 bits of randomness behind the 12-word recovery phrase into the key that wraps the data key.

    Apple CryptoKit

  • SHA-256

    Fingerprints: the first 16 hexadecimal characters of the hash of a secret value, stored alongside it so duplicates can be spotted and the hygiene score computed without unlocking. Also the BIP-39 checksum. Hashing, not encryption.

    Apple CryptoKit

  • BIP-39 mnemonic encoding

    Writes 128 bits of randomness as 12 English words from the standard list, so a recovery phrase can be copied onto paper and typed back.

    Encoding only, not a cipher

  • SecRandomCopyBytes

    Source of the 256-bit data key, every salt and the recovery-phrase entropy — the operating system's random generator.

    Apple Security framework

One data key, one to three locks

Everything sensitive is encrypted with a single data key: 256 random bits generated the first time the app runs. The first lock is always present — the data key is stored in the iOS Keychain, in an access group private to the app and its share extension. Its default protection is after first unlock and it is not marked device-only, so iOS includes it in encrypted computer backups, iCloud Backup and device-to-device migration. That is the whole of zero set-up: there is nothing else to remember.

The second and third locks are optional. A master password is run through PBKDF2 to derive a key that wraps a copy of the data key; a recovery phrase is run through HKDF to derive another that wraps a second copy. Either one can recover the data key on a device where the Keychain entry is missing, after which the app puts it back into that device's Keychain. The data key itself never changes, so adding, changing or removing a lock re-encrypts nothing. The wrapped copies, their salts and a small verifier are stored with the database; on their own they contain no usable key.

Strict mode, off by default, changes the Keychain entry to when unlocked, this device only and binds it to the current Face ID enrolment. Reading it then always requires Face ID, re-enrolling Face ID invalidates it, and it is never included in any backup. The app cannot turn it on without Face ID or Touch ID, and it asks you to set up the safety net first.

Who can decrypt your secrets: whoever holds the data key — that is, this iPhone's Keychain, or you with your master password or recovery phrase. Not MNV LIMITED: we hold no copy of the data key, no master key, no escrow and no backdoor, and could not open a vault if asked. The consequence is stated wherever it matters in the app: if the Keychain entry is lost and no safety net was set, the secret values cannot be decrypted by anyone. Names and settings stay readable; the values return only from a backup file you exported.

Not everything is encrypted, on purpose. Names, providers, environments, tags, dates, variable names, Base URLs, the masked hint (provider prefix plus the last four characters) and the fingerprint are stored readable so that the list, search, expiry reminders and the hygiene score work while secrets are locked. They reveal about as much as a provider's own console shows. The whole database is additionally covered by iOS data protection.

No network

BABEL TOKEN has no networking capability: no URLSession, no sockets, no web view, no third-party SDK — in the app or in its share extension. The Documentation and Console links on a key's page are handed to Safari; the app itself opens nothing. Universal Clipboard is Apple's device-to-device feature, and the app's part in it is writing to the system pasteboard with an expiry. This is why the App Store privacy label is Data Not Collected and why the privacy policy can say, literally, that nothing is collected.

What the app never does

  • Validate a key against its provider, or tell you whether it still works. Expiry and rotation are computed only from dates you enter.
  • Fetch model lists, balances or usage from any service.
  • Collect, transmit or store any data anywhere but on your iPhone. There is no server to send it to.
  • Keep a backdoor, master key or key escrow. We could not decrypt your data if asked.
  • Implement its own cryptography or bundle a third-party cryptographic library. Every primitive comes from Apple's frameworks.
  • Claim absolute security. Encryption raises the cost of an attack; it cannot protect an iPhone that is already compromised, or a key after it has been pasted somewhere else.

Export classification

BABEL TOKEN contains encryption and is therefore subject to the US Export Administration Regulations (EAR). MNV LIMITED has self-classified it as ECCN 5D992.c under Note 3 to Category 5 Part 2 of the Commerce Control List — the mass market note — because it is sold to the public through the App Store, its cryptographic functionality cannot be changed by the user, it installs without support from us, and its details are published on this page and inside the app.

Every algorithm is a published standard implemented by Apple's system frameworks. That makes the item eligible for self-classification: no Commodity Classification request (CCATS) and no export licence is required, and — under the current text of EAR §740.17 — no encryption registration. The app is not offered in embargoed destinations. A classification record is retained under EAR Part 762 and can be produced on request.

For each build we answer the App Store Connect export compliance questionnaire as follows. Does the app use encryption: yes. Does it qualify for an exemption: no. Does it use proprietary or non-standard algorithms: no. Does it implement algorithms instead of, or in addition to, those in Apple's operating system: no. BIP-39 encodes random bits as words; it is not a cipher and does not change these answers.

Self-classification is our own good-faith assessment, not an official ruling.

This page reflects the app as of 2026-09-13; the same information is shown inside the app under Me › About › Encryption & export compliance.