The simplest way to picture a photo vault

Imagine putting a photograph inside a safe.

  • The photo is the plaintext: the original readable information.
  • The safe’s key is the encryption key: a long, random secret used by the encryption algorithm.
  • The locked safe is the ciphertext: data that should look meaningless without the key.
  • Your password, PIN, or pattern proves that the app may use the key. It should not be the key used to encrypt every file directly.

The analogy has one important limit. A physical safe contains one object. A phone can hold many copies: the original in Photos or Gallery, an imported vault copy, a thumbnail, an edited version, a message attachment, a cloud copy, and an export. Encrypting one copy does not automatically protect or delete the others.

Diagram showing source copies before a vault, encrypted data and an open screen inside the vault workflow, and exported copies outside the vault
A vault protects the data it manages while locked. Source copies, displayed plaintext, and exports belong to different security boundaries.

What happens when you import a photo

A well-designed import flow usually follows four broad steps:

  1. The app reads the selected file. At this moment, the source photo may still exist in the system photo library.
  2. The app creates or retrieves a random vault key. Secure applications use operating-system cryptographic random-number generators rather than a memorable word or predictable value.
  3. The app encrypts and authenticates the photo. The output is ciphertext plus the information needed to verify that it has not been altered.
  4. The app stores the sealed result. When the vault is locked, ordinary app access to the decryption key is removed.

Many modern vaults use AES-GCM. AES is the block cipher standardized in NIST FIPS 197, and GCM is an authenticated-encryption mode specified in NIST SP 800-38D.

That standards pedigree matters, but an algorithm name alone does not prove that an app is secure. Key generation, nonce handling, metadata, backups, error handling, and the lifetime of plaintext all matter too.

Why your password should not be the file key

People choose passwords, PINs, and patterns that they can remember. Cryptographic keys should be long, random, and impractical to guess. Those are different jobs.

A sound design separates the credential from the random key that protects the vault:

  1. You enter a password, PIN, or pattern.
  2. A key-derivation function processes it with a unique salt and deliberately consumes computing resources.
  3. The result unlocks or unwraps a random vault key.
  4. The vault key anchors separate keys for content, metadata, or individual files.

Argon2id is one modern key-derivation choice. RFC 9106 describes Argon2 as a memory-hard function and includes Argon2id as its primary variant. Memory-hard processing makes each guess more expensive, especially at scale. It does not turn 1234, a short square, or a reused password into a strong secret.

This layered model also makes password changes more practical. The app can change how access to the stable vault key is wrapped instead of decrypting and re-encrypting every photo. OWASP describes the same general separation as a data-encryption key protected by a separate key-encryption key in its Cryptographic Storage Cheat Sheet.

Why authenticated encryption matters

Encryption answers one question: “Can someone understand this data without the key?”

Authentication answers another: “Has this encrypted data been changed?”

AES-GCM combines both jobs. When an app seals a file, it also produces an authentication tag. If the ciphertext or its protected context is changed, verification should fail and the app should refuse to release plaintext. NIST calls this authenticated encryption with associated data in SP 800-38D.

Associated data can bind an encrypted record to facts that should not be interchangeable—for example, its vault, file, record type, or chunk position. This helps prevent a valid encrypted block from being silently moved into the wrong context.

Failing closed has a tradeoff: damaged or modified ciphertext may become unavailable. That is safer than displaying unverified output, but it is also why irreplaceable files need a tested backup.

A photo is more than its full-size pixels

Private media can leave clues even when the original file is encrypted. A complete vault design must consider:

  • filenames and user labels;
  • dates, locations, and other metadata;
  • thumbnails and previews;
  • edits and optimized versions;
  • Live Photo or paired-video resources;
  • album membership and search indexes;
  • temporary files created during viewing or export.

If a vault encrypts the full-size photo but leaves a readable thumbnail or descriptive filename on disk, the most sensitive information may still be exposed. Good product documentation should state whether its protected boundary includes content, metadata, thumbnails, and temporary files.

What “locked” actually means

When a vault is locked, the app should no longer have ordinary access to the active plaintext keys it needs to display files. The encrypted files can remain on storage; without the required key, those files should not be meaningfully readable.

Unlocking changes the situation. To display an image, the app must decrypt enough data for the operating system to render it. Plaintext then exists in memory and on the display path. App lifecycle locking, short key lifetimes, and protected temporary storage can reduce exposure, but they cannot make visible plaintext invisible.

On Android, the Android Keystore can keep eligible key material non-exportable and can bind it to secure hardware on supported devices. Apple’s Keychain data protection similarly provides protection classes and Secure Enclave-enforced access controls for sensitive items.

These platform features are valuable, but they do not make an already-compromised, unlocked phone safe. Malicious software controlling the app or operating system may be able to request key operations or observe plaintext while the user is viewing it, even when the key itself cannot be exported.

Hidden album, device encryption, and an encrypted vault are different

These protections can work together, but they solve different problems.

Protection What it mainly protects Unlock authority Important limit
Hidden album or gallery hiding Accidental discovery inside a photo app Usually the device or photo-app lock The item may remain in the same photo library and cloud-sync model
Phone storage encryption Data on a locked or powered-off device Device passcode and platform keys Once the device is unlocked, authorized apps can use their allowed data
Encrypted photo vault The app-managed copy while the vault is locked Vault credential plus the app’s key design Originals, exports, screens, and other copies remain separate
End-to-end encrypted cloud copy Content between authorized endpoints Keys available to authorized devices The provider may still process account, timing, size, and traffic metadata

“Encrypted” is therefore not a complete answer. Ask which copy, against whom, while the device is in what state, and who can obtain the key.

What zero-knowledge encryption means

Zero-knowledge encryption is commonly used for a service architecture in which the provider stores encrypted data but does not have the keys needed to decrypt the user’s content. Encryption happens before the data reaches the provider, and decryption happens on an authorized user device.

A simple analogy is a hotel that rents you a safe but never receives the combination. The hotel can store and move the safe. It can see that a safe exists and how large it is. It cannot open the safe for you if you forget the combination.

For a cloud vault, the central questions are:

  • Are encryption keys created or derived on the user’s device?
  • Does the provider ever receive the plaintext key or credential?
  • Can account support reset access and reveal the old files?
  • Does a new device need a recovery secret or approval from an existing device?
  • What account, timing, device, storage-size, and network metadata remains visible?

Zero knowledge does not mean the service learns literally nothing. It describes access to encrypted content, not the absence of all service metadata. It also does not protect an unlocked endpoint: a compromised phone can observe a photo after legitimate decryption.

Zero knowledge vs end-to-end encryption

The ideas overlap, but the emphasis is different.

  • End-to-end encryption describes a path: only authorized endpoints should decrypt the content while it moves or syncs through a service.
  • Zero-knowledge encryption emphasizes provider access: the provider should not possess the authority needed to decrypt stored user content.

A system may use both descriptions, but readers should look for a documented key and recovery design rather than relying on either label alone.

The recovery tradeoff

If the provider truly lacks decryption authority, it cannot simply email a reset link that restores access to old encrypted content. Recovery needs another source of authority, such as a recovery phrase, a recovery key, approval from an existing device, or a previously exported key.

This creates a real tradeoff: stronger provider separation places more responsibility on the user. Losing every authorized device and every recovery secret can make the data permanently inaccessible.

Seven questions to ask before trusting any vault app

1. What exactly is encrypted?

Look for an explicit statement about original content, thumbnails, filenames, metadata, notes, and temporary files. A cipher name by itself is not enough.

2. Where do the keys come from?

The app should use cryptographically secure randomness for content keys. A password or pattern should go through a documented key-derivation design rather than becoming a file key directly.

3. Does it detect tampering?

Look for authenticated encryption such as AES-GCM or ChaCha20-Poly1305, or another well-documented encrypt-then-authenticate construction. OWASP recommends authenticated modes where available.

4. What happens to the original?

Import and deletion are separate operations. Check Photos or Gallery, Recently Deleted or Trash, Files, cloud libraries, messages, shared albums, and other devices.

5. What happens if the phone is lost?

An encrypted vault with no recoverable copy protects privacy but not availability. Understand whether recovery needs the original device, an encrypted backup file, a phrase, an account, or some combination.

6. Can the provider reset access and reveal the old data?

If yes, the provider or recovery system has some path to decryption authority. That may be an intentional convenience, but it should be disclosed clearly.

7. Are the limitations written down?

Trustworthy documentation should discuss compromised devices, weak credentials, exports, deletion limits, backups, and unrecoverable data—not only cipher names.

A fictional example

In this fictional scenario, Maya imports a passport scan into a vault and confirms that the full-resolution copy opens after locking and unlocking. She then creates and tests the documented encrypted backup. Only after both checks does she review Photos, Recently Deleted, Files, Messages, and her cloud photo library for unwanted source copies.

The vault protects its managed copy while locked. The backup protects against device loss. Removing other copies reduces exposure outside the vault. These are three separate jobs, and skipping any one of them changes the result.

Four-step diagram showing a photo entering an app, a random vault key, authenticated encryption, and locked ciphertext
The memorable credential authorizes access to a random key; authenticated encryption turns the managed photo into sealed ciphertext.

What encryption cannot protect

An encrypted photo vault cannot:

  • remove originals, exports, messages, backups, or recipient copies automatically;
  • stop another camera from photographing an unlocked screen;
  • make a weak or observed password or pattern unguessable;
  • protect plaintext from a compromised operating system during unlock;
  • guarantee physical erasure from flash storage, snapshots, or old backups;
  • recover data when every valid ciphertext copy or required recovery secret is lost;
  • hide all evidence that the app or encrypted storage exists.

The right mental model is simple: encryption is powerful inside its stated boundary. Good privacy comes from understanding that boundary and managing every copy that crosses it.

Questions people ask

Can someone read a vault by copying its files?

A sound design aims to make copied ciphertext unreadable without the required key material. This describes an offline copy. Someone controlling the original device while the vault is unlocked faces a different—and much easier—attack surface.

Is AES-256 enough to prove an app is secure?

No. AES-256 is a standardized cipher, but the surrounding design determines whether it is used safely. Key generation, authenticated mode, unique nonces, metadata, temporary files, backups, and error handling all matter.

Are thumbnails encrypted too?

They should be inside the vault’s protected boundary if they reveal private content. Other apps or the operating system may still hold previews created before import or after export.

Does changing a password re-encrypt every photo?

Not necessarily. In a layered design, the password controls access to a stable random vault key. The app can rewrap access to that key without re-encrypting every content object solely because the credential changed.

What happens if encrypted data is damaged?

Authenticated decryption should fail when ciphertext or its protected context does not verify. That prevents silent acceptance of changed data, but it can make a damaged file unavailable. Keep a tested backup for anything irreplaceable.

Is an encrypted backup automatically private and recoverable?

No. Privacy depends on who has the keys; recovery depends on retaining both the required authority and a valid encrypted copy. A recovery phrase cannot recreate a missing backup file.

Primary sources and further reading

For NullVault’s product-specific implementation, see the separate security architecture and security limitations.

Guide reviewed: 30 August 2026.