Plausible Deniability and Pattern-Separated Vaults

Vaultaire’s plausible-deniability feature uses separate patterns to address separate encrypted vault indexes without showing a cross-vault list. This can conceal other vaults during ordinary interface inspection, but the current on-disk layout exposes an encrypted index-file count to an examiner with app-container access.

What Plausible Deniability Actually Means

In its strongest cryptographic sense, plausible deniability means observable storage does not prove that additional protected content exists. In everyday product language, the phrase is also used for decoy credentials that reveal one view while withholding another. Those are different standards, and Vaultaire’s current implementation meets the interface-compartmentalization goal rather than information-theoretic deniability.

Most vault apps give you one vault behind one password. If someone forces you to open it, everything is exposed. Some apps offer a “decoy mode” where you can set a second password that shows a fake screen. But those implementations are usually cosmetic. A forensic examiner can look at the app’s data, see configuration flags, notice the size of encrypted data does not match the visible files, or find metadata that betrays the existence of a hidden layer.

Vaultaire takes a pattern-addressed approach. Every valid pattern on the 5×5 grid derives a different candidate vault key. The app hashes that key to compute an expected encrypted-index filename, then opens and authenticates that index if it exists. It does not present a plaintext registry mapping patterns or user-facing vault names, though the encrypted index files themselves can be enumerated and counted.

If the derived index exists and AES-GCM authentication succeeds, you see that vault’s files. If it does not, Vaultaire presents an empty state and can create a new vault for that pattern. There is no lock-screen error naming another vault or showing a list. That quiet interface helps during casual inspection, but it does not erase the filesystem evidence described below.

How It Works Under the Hood

The technical foundation combines pattern-derived addressing with authenticated encryption. Different patterns produce different candidate keys and filenames. AES-GCM then provides an explicit integrity check: a correct key authenticates the encrypted index, while an incorrect key fails. That authentication result is useful for safety, but it also means copied data supports offline guess verification.

Different Patterns, Different Keys

When you draw a pattern, Vaultaire serializes the dot sequence and grid size, then runs 600,000 rounds of PBKDF2-HMAC-SHA512 with a random device-wide Keychain salt. The function outputs a 256-bit vault key. Different pattern input is expected to produce an unrelated key, but the security of the credential remains limited by the pattern’s guessability. A 256-bit output does not give a human pattern 256 bits of entropy.

Each Key Decrypts Its Own Blob

Vaultaire stores each vault’s file map and wrapped random master key in an AES-256-GCM encrypted index. When you draw a pattern, the app derives the candidate vault key and checks the corresponding key-fingerprint filename. If the file exists, authenticated decryption either succeeds or fails; AES-GCM does not produce accepted meaningless plaintext. If no valid index opens, the user interface offers an empty state without listing other vaults.

No Plaintext Cross-Vault Catalog

Vaultaire does not keep a user-facing database table that maps patterns to readable vault names. The ordinary unlock flow addresses one index through the derived key. On disk, however, each vault has a `vault_index_<fingerprint>.bin` file, and the app itself includes code to enumerate those filenames for storage maintenance. The fingerprints do not reveal their originating patterns, but their count reveals the number of local indexes.

Both vaults are equally real. Both are encrypted with the same algorithm. Both produce the same kind of encrypted output. There is no flag, no marker, no metadata that labels one as “real” and the other as “decoy.” As far as the math is concerned, they are identical.

The Decoy Vault Strategy

Plausible deniability only works if you have something to show. An empty vault is suspicious. A vault that obviously contains nothing worth protecting is suspicious. The strongest defense is a vault that looks exactly like what someone would expect to find.

Setting Up Your Decoy

Choose a second pattern — one you can draw quickly and naturally under pressure. Create a vault with that pattern. Fill it with content that makes sense for someone who uses a vault app: maybe some personal photos you would prefer to keep private but that are not sensitive, a few financial documents, some notes. The content should be believable and slightly embarrassing — just enough that someone searching your phone thinks they have found what you were hiding.

Making It Convincing

A good decoy vault has a few characteristics. It should contain a reasonable number of files — not too few (suspiciously empty) and not too many (why would you protect that much mundane content?). The files should be recent enough to suggest active use. And ideally, the content should provide a plausible reason for why you installed a vault app in the first place.

Someone limited to the unlocked interface sees the selected vault and no cross-vault picker. That can reduce casual disclosure. Someone with filesystem access can count encrypted indexes and may know that more than one local vault exists, even if they still cannot connect an index to a pattern or read its contents.

Under Pressure

If you are ever coerced into unlocking your device, draw the decoy pattern. The vault opens. The files appear. In the ordinary interface, there is no hidden menu or cross-vault list to discover. The person holding your phone sees one unlocked vault. That can make the disclosure coherent during casual inspection, while a filesystem examination may still reveal additional encrypted indexes.

Your sensitive vault does not appear in the interface unless its pattern is drawn. It is not listed behind a hidden menu. Its encrypted index still exists in the app container, so the feature should not be presented as protection against every form of compelled disclosure or forensic analysis.

The Security Boundary, Precisely

Vaultaire can make strong claims about encrypted content and a narrower claim about the interface. AES-GCM protects what an index and its files contain. Pattern-addressed routing keeps other vaults out of the visible unlock flow. Neither property makes the number of encrypted index files invisible to an examiner who can read the app container.

Encrypted Content Remains Confidential

AES-256-GCM is designed to conceal plaintext and detect modification when keys and nonces are handled correctly. An examiner can identify Vaultaire’s index and blob files from their names and location, but cannot read the protected file map, wrapped master key, filenames, metadata, thumbnails, or file content without the relevant keys.

Enumerable Indexes, No Plaintext Pattern Map

The filesystem can answer how many encrypted vault indexes are present because each index has its own file. What it does not provide is a plaintext map from those fingerprints to the patterns that generated them, user-facing vault labels, or decrypted contents. That is a useful boundary, but it is not hidden count.

Offline Guess Verification Exists

An attacker who copies the device salt and encrypted app data can derive a candidate key from a guessed pattern. The corresponding index fingerprint tells the attacker whether a matching filename exists, and AES-GCM authenticated decryption confirms the guess with overwhelming confidence. PBKDF2 makes each guess more expensive; it does not remove this offline test or add entropy to a weak pattern.

What the Empty State Accomplishes

On the lock screen, Vaultaire does not announce “wrong pattern” or display which other vaults are available. A nonmatching pattern reaches an empty or creation flow, so a person limited to interacting with the interface gains no vault list. This presentation benefit should not be extrapolated to an attacker who has copied and analyzed the underlying files.

Who Needs Plausible Deniability

You might think plausible deniability is only for spies and whistleblowers. In reality, millions of ordinary people face situations where the ability to protect information under coercion is not a luxury — it is a necessity.

Journalists and Their Sources

Investigative journalists often carry sensitive material: source identities, leaked documents, interview recordings. In many countries, journalists are routinely detained and their devices searched at borders, checkpoints, or during raids. A decoy vault containing innocuous notes and published photos provides cover, while the real vault protects sources whose lives may depend on anonymity.

Activists and Organizers

Political activists, labor organizers, and human rights workers may operate in environments where their phones are surveillance targets. Separate patterns can compartmentalize what appears during ordinary app use, but a confiscated or compromised phone can expose encrypted-index counts and support offline pattern guessing. Operational security must extend beyond the app.

People in Abusive Situations

People documenting abuse may need to separate sensitive evidence from material they can safely show. A second vault can reduce disclosure to someone limited to the app interface. It cannot guarantee safety against device monitoring, spyware, coercion, or filesystem examination, so users in danger should follow guidance from a qualified local support organization.

Travelers Crossing Borders

Border-search powers and traveler obligations vary. Opening one Vaultaire pattern does not display a cross-vault list, but it does not make other encrypted indexes completely undetectable to a forensic inspection. Minimize the sensitive data you carry and obtain current legal advice for your route and circumstances.

Anyone Who Values Privacy

You do not need to be in danger to deserve privacy. Maybe you keep a private journal. Maybe you have medical information you do not want anyone to stumble across. Maybe you simply believe that not every piece of your digital life should be accessible to anyone who picks up your phone. Pattern-separated vaults strengthen interface privacy by limiting what an ordinary unlock reveals, while the encrypted index count remains visible to a filesystem examiner.

How This Compares to Other Vault Apps

Many vault apps treat security as an access-control problem: one credential gates one visible container. Some products add a fake PIN or decoy mode. The strength of those features depends on storage design, not the marketing label; a visible configuration flag or separate decoy database can disclose that another mode exists.

The One-Vault Problem

A one-container design has a direct coercion problem: once its only credential is disclosed, all content behind that credential becomes available. Products differ in their current feature sets, so evaluate the actual storage and decoy implementation rather than assuming that a named competitor uses one fixed model.

Cosmetic Decoy Modes

A fake-password feature can be useful against casual inspection, but its forensic value depends on whether the device stores a detectable decoy flag, a second database, or distinguishable file sizes. Without a published design or audit, the label alone does not establish either strong deniability or failure.

Vaultaire’s Approach Is Architecturally Different

Vaultaire builds pattern separation into its normal unlock path. There is no special fake-PIN flag needed to decide whether a vault is a decoy; each configured pattern addresses an ordinary encrypted vault. The separate index files remain visible as encrypted containers, so the architectural distinction is strongest in the user interface and content isolation, not in forensic count hiding.

The result is a consistent experience: no vault is labeled “real” or “fake,” and each requires its own authenticated unlock or recovery path. Without the required vault and master keys, the encrypted contents remain unavailable. The container’s existence is not cryptographically erased.