Security

This is a plain-language summary of how Vaultumi protects your files, and just as importantly where that protection stops. It is the author’s own description of what the code does, written from the project’s security architecture and threat model. It is not an independent assessment, an audit or a certification.

What it is built on

• Everything you store is encrypted on the device before it is written to the app’s storage.
• No server, no account, no analytics. There is nothing for us to breach remotely and nothing for us to hand over.
• A forgotten PIN is recoverable with the recovery code, but nobody without a secret can open the vault.
• Failure should never silently lose data: an item exists completely or not at all, and no number of wrong PINs deletes anything.
• Only Apple-provided cryptographic primitives (CryptoKit, CommonCrypto, Security) and no third-party code. The one exception in spirit is that scrypt is our own implementation on top of Apple’s PBKDF2, because Apple ships no memory-hard key derivation function.

How your keys work

1. Each vault has a random 256-bit master key. It is stored only in wrapped (encrypted) form.
2. Your 6-digit PIN is stretched with scrypt (32 MiB) and then combined with a random pepper that lives only in this iPhone’s Keychain. The result wraps the master key. The pepper is never part of any backup, so a copy of the vault files cannot be used to test PIN guesses without it.
3. The recovery code (160 random bits, shown once, not stored) separately wraps the same master key, through scrypt with 64 MiB.
4. Face ID, if enabled, unlocks a random key held in the Keychain behind the system Face ID prompt. Vaultumi only receives a yes or no from iOS and never sees your face data. If your enrolled faces change or the passcode is removed, iOS invalidates that key and your PIN keeps working.
5. Every photo or video has its own random key. Media is encrypted in 1 MiB chunks with authentication, so tampering, truncation and reordering are detected. Metadata (file names, dates, albums, dimensions, hashes) and thumbnails are sealed too.

Changing your PIN re-wraps only the master key; your media is not touched. Compromise of one file key exposes only that file.

Algorithms

The scrypt implementation is checked against the RFC 7914 test vectors, but it is custom code and still needs external review.

PIN guessing and Face ID

A 6-digit PIN has only a million possibilities. It is a convenience lock, not a strong secret. Its strength rests on the scrypt cost, the device-only pepper and a limiter that slows down guessing through the app. Obviously guessable PINs such as repeated digits and simple runs are rejected.

• Vaultumi never erases anything because of wrong PINs.
• Waits are measured on a monotonic clock, so changing the date or time does not shorten them. Restarting the iPhone starts the current wait again in full.
• The PIN check before sensitive actions (changing the PIN, a new recovery code, creating a decoy vault, creating a backup, deleting all data) counts toward the same limit.
• The limiter slows down someone using the app. It does not slow an attacker who has both the vault files and the pepper and runs the key derivation offline. For that attacker a 6-digit PIN falls in hours to days.
• The recovery code and a strong backup passphrase are the strong secrets.

Storage and crash safety

• The vault lives in the app’s private storage with iOS file protection. It is not visible in the Files app or through file sharing.
• An item exists if and only if its metadata record exists, and that record is written last. If an import is interrupted, nothing partial remains and you can import again without duplicates.
• Before any original is offered for deletion, the encrypted copy is fully decrypted and its SHA-256 compared with what went in.
• Decrypted data touches disk only in short-lived temporary files (for example to play a video or share an item). They are deleted when you are done, when the vault locks and at launch. If the app is killed while viewing, a file can remain until the next launch.
• The app locks when you leave it, immediately or after a delay you choose, and an opaque cover hides the app switcher snapshot. A cover also appears while the screen is recorded or mirrored.

What someone with a copy of your vault files, but no keys, can still learn: the number of items, the approximate size of each, file modification times, whether an item is a Live Photo, that a second (decoy) vault exists, and the key-derivation settings. File names, dates, albums, media types, dimensions, hashes and thumbnails are inside encrypted blobs.

Network and third parties

As of the last audit (30 October 2026), the code makes no network requests of its own, uses no web views, and has no analytics, advertising, crash-reporting or other SDKs and no Swift package or CocoaPods dependencies. The only network traffic is Apple’s StoreKit and the App Store, for purchases and subscription status. The audit is repeated before each release. It does not cover what iOS itself does, such as iCloud device backup if you have it on, share-sheet destinations you choose, or iCloud Photos downloading an original when you import it.

Backups and new phones

• iPhone backups (iCloud or computer) include the encrypted vault files on purpose, so a restored phone still has them. They do not include the pepper. A restored phone therefore cannot be opened with the PIN: use the recovery code, then set a new PIN. Someone who holds only your iPhone backup has ciphertext they cannot test PIN guesses against.
• Vaultumi backup files (.vaultumibackup) are encrypted with a passphrase you choose or the app generates (at least 12 characters if you choose your own), work on any iPhone, and need nothing else. They are only as strong as that passphrase. Restoring adds items and never replaces or deletes. A hostile or damaged backup file is validated before anything is restored.
• The decoy vault has no recovery code. After moving to a new phone it cannot be reopened; create it again.

The full walkthrough is in the backup and recovery guide.

What it is built to protect against

Confidentiality and integrity of your vault data at rest, in app storage and in backup files, against these kinds of people:

• A casual snooper who briefly has your phone and tries PINs through the app.
• Someone who knows your habits and may guess likely PINs.
• A thief with a locked phone.
• Someone who knows your device passcode, who can open Settings and take backups, but who does not have your Keychain secrets.
• Someone who holds a copy of your vault files, such as a device backup or a .vaultumibackup file, with unlimited offline compute but without the device-only pepper.

It is also built to survive crashes, low storage and corrupted files without silent data loss, and not to leak data to the network or to third parties.

What we cannot protect against

No protection is claimed for any of the following:

• A compromised, jailbroken or malware-infected device, or one with a hostile management profile. Anything that can read the app’s memory or Keychain can open an unlocked vault.
• Someone watching your screen or PIN entry, and coercion. An observed PIN defeats it.
• A weak backup passphrase, or a PIN that is still guessable.
• Forensic analysis of the device, of free space or of flash remnants, and secure erasure. Purge removes the app’s files; it does not promise secure erase.
• Attacks on Apple’s platform: the Secure Enclave, Keychain, Face ID implementation or iCloud.
• Screenshots and screen recordings. iOS offers no way to block them. Screenshots you take go to your Photos library, outside the vault. AirPlay output of video is not covered by the screen-capture cover.
• Losing every secret. A person who loses their PIN, recovery code and every backup (or its passphrase) loses the data. This is by design: there is no back door.
• Copies outside the vault. Exported files are no longer protected by Vaultumi. Originals deleted from Photos stay in Recently Deleted for about 30 days and may exist in synced copies.
• Rollback. Someone who swaps in an older copy of the vault files is not detected, and an attacker who can delete or corrupt files can cause denial of service. Tampering is detected, not prevented.

Known limitations

• The decoy vault is a convenience against casual inspection, not a hidden-volume system. Its directory and header exist on disk, storage use can differ, and a failed PIN attempt takes measurably longer only when a decoy exists. Do not rely on it against a technical adversary.
• The master key is not rotated when you change your PIN. Someone who holds an old copy of the header, your old PIN and the same device pepper can still open the vault.
• “Delete originals” removes the original photo resource, so for an edited photo the edit is not what was imported.
• The PIN space is 10⁶.
• Real Face ID behaviour, temporary-file residue, app-switcher snapshots and screen-recording handling still need verification on physical devices.

Review status

Vaultumi has not been independently reviewed, audited or certified. Before anyone should make stronger claims than “encrypted with standard Apple primitives”, the project lists these as required: an independent cryptographic review (in particular of the hand-written scrypt, the media file format, key wrapping and the backup format), a review of Keychain and biometric usage, a penetration test of the running app on a physical device, and legal review. Treat Vaultumi as one sensible layer, and keep independent backups of anything you cannot afford to lose.

Reporting a security issue

Good-faith security research is welcome. Email [OWNER: security contact email] with details, and please do not include real personal data or your secrets. [OWNER: add a response commitment and, if desired, a PGP key.] For anything else, see support.