Protection starts before upload
Native vaults work locally without a Revault account. File contents, filenames, MIME types, thumbnails, vault names, folders, tags and favourites are encrypted on-device. Local use does not upload vault files to Revault. Native cloud sync and sharing are optional, separate operations.
The model assumes a trustworthy operating system, installed app and cryptographic random source when a vault is created or unlocked. Someone with only encrypted files and key wrappers cannot decrypt them without the required secret. Malware or a compromised app running while a vault is open can capture plaintext and keys.
Independent keys for every vault
Each vault starts with a random 256-bit AES master key, generated using the operating system’s cryptographic random source. The gesture does not directly determine this key. Every vault has independent master key material, so disclosure of one vault key does not derive another.
A device pattern combines its ordered dot sequence with a random 256-bit device secret. The resulting input is normalized with NFKC and passed to PBKDF2-HMAC-SHA-256 with a fresh 128-bit salt and 600,000 iterations. The derived 256-bit key wraps the master key using AES-256-GCM. The app does not save a plaintext pattern or a separate pattern fingerprint.
Patterns use a 5 × 5 grid with six to 25 distinct dots and must be unique across vaults enrolled on the same device. A matching pattern opens only its vault; other vault names and contents remain hidden. Predictable gestures are still easier to guess. A person who obtains both a device secret and its encrypted wrapper can attempt offline pattern guesses.
Opening a native vault requires its local pattern or an explicit recovery flow, not a Revault account or passkey. Optional cloud sync uses the platform’s Apple or Google authorization, and store purchases use the platform billing account. Neither cloud authorization nor a purchase supplies a vault decryption key.
| Purpose | Construction |
|---|---|
| Vault master key | Random 256-bit AES key |
| Key wrapping | PBKDF2-HMAC-SHA-256 · 600,000 iterations · 128-bit salt → AES-256-GCM |
| Metadata & thumbnails | AES-256-GCM · random 96-bit nonce · 128-bit authentication tag |
| File key derivation | HKDF-SHA-256 · per-file random 256-bit salt · 256-bit AES output |
| Recovery secret | Generated: 18 random words (198 bits); custom: at least 6 distinct words and 32–512 characters |
Device-only key protection
On iOS, the device lock is stored as a nonsynchronizing Keychain item using WhenUnlockedThisDeviceOnly protection. It is accessible only while the device is unlocked and does not migrate through Keychain sync. The stored secret is not a Secure Enclave key.
On Android, the device lock is encrypted using AES-256-GCM under a non-exportable Android Keystore key that requires an unlocked device. The encrypted lock file lives in the app’s no-backup directory. Keystore hardware backing depends on the device; the app does not promise that every device uses hardware-backed keys.
Local unlock secrets are excluded from native cloud sync and portable vault backups. Possession of an Apple or Google account does not recreate those secrets or automatically unlock a restored vault. A new device must verify the independent recovery secret and enroll its own pattern.
Confidentiality and tamper detection
Vault metadata, file metadata, thumbnails, and wrapped keys use AES-256-GCM with 128-bit authentication tags. Every independent encryption uses a fresh random 96-bit nonce. Decryption verifies the tag before returning plaintext; modified ciphertext or a wrong key causes authentication to fail.
Additional authenticated data binds each encrypted object to its format version, vault identifier, object identifier, and purpose. For example, a thumbnail and file metadata record use different contexts. Moving an encrypted object into a different vault or substituting it for another object changes the authenticated context and fails verification.
Authenticated context does not hide identifiers and does not prove freshness. A valid older record can still have a valid tag. Application revision checks detect ordinary concurrent updates, but this is not a cryptographic defense against a malicious service replaying a complete older state.
Large files use authenticated segments
Native file encryption uses the AES-256-GCM-HKDF-SHA-256 streaming construction described by Tink. iOS uses CryptoKit for AES-GCM and HKDF; Android uses platform cryptographic primitives. Each new stream has a 40-byte header containing its length marker, a random 32-byte salt and a random seven-byte nonce prefix.
HKDF derives a separate file encryption key from the vault master key. Its context includes the vault and file identifiers, plaintext byte length, and configured segment size. Each segment’s 12-byte nonce combines the random prefix, a four-byte segment counter, and a final-segment flag. Segments carry 128-bit GCM tags.
The native apps process files in bounded segments of approximately 5 MiB. Segment counters, the final-segment flag and expected byte lengths detect altered, reordered or truncated segments. Each segment is authenticated before use, and a private preview is published only after its file finishes decrypting. Incomplete output is discarded on failure; retries transfer the existing encrypted bytes.
The construction follows the Tink AES-GCM-HKDF streaming specification. Revault’s implementation and segment configuration have not been independently audited or certified by Tink.
Private storage, imports and previews
Encrypted vault files live in private app storage. Filenames, MIME types, folders, tags, favourites and thumbnails are authenticated encrypted records. Search and tag filtering operate on the active vault’s decrypted metadata after unlock; there is no plaintext server search index.
Photo, video and file imports can use private temporary staging before encryption. In-vault camera capture does not automatically save a copy to the gallery. Importing from Photos or another provider leaves that provider’s original intact. Optional media optimization happens locally before encryption and changes only newly imported media.
Private previews require temporary plaintext while they are open. The apps remove their temporary previews on close, lock and subsequent startup; iOS applies complete file protection to decrypted preview files. Files explicitly exported to another app leave the vault’s protection. Temporary-file deletion is not a guarantee of forensic erasure.
Optional native cloud sync
Sync is off by default and enabled separately for each vault on each device. iOS stores encrypted records and file segments in the user’s private CloudKit database in iCloud. Android uses Google Drive’s private appDataFolder. Neither transport requires a Revault account or uploads native sync data to Revault’s web cloud.
The cloud receives encrypted metadata, file segments and key wrappers, not a plaintext vault master key, local device secret or recovery secret. Another device on the same platform needs the same native cloud account and the vault recovery key to enroll its own local pattern. Apple and Google authorization controls access to the encrypted records, not their decryption.
Turning sync off stops further transfers for that vault from the current device; existing encrypted cloud copies remain. Sync changes and deletions can propagate, and concurrent edits may require conflict review. iCloud and Google Drive are separate stores, with no automatic cross-platform bridge. Use an encrypted phone transfer to move between iPhone and Android.
Recovery is a second path to the same key
Generated recovery phrases contain 18 independently chosen words from a bundled 2,048-word list, providing 198 bits of randomness. You can instead choose a custom phrase with at least six distinct words and 32–512 characters; its strength depends on your choices. Both independently derive a wrapping key using PBKDF2-HMAC-SHA-256 and a fresh salt, then wrap the same vault master key with AES-256-GCM. Anyone with the phrase and encrypted vault can decrypt it.
The recovery secret is shown during setup and is not persisted in native app storage or uploaded to native cloud storage. Keep it separately from the encrypted files. Enrolling another device requires the encrypted vault from the original native cloud account, or an encrypted backup, plus the recovery key. A secret cannot restore missing file data, and Revault has no provider-held reset key.
A portable .qvault backup contains encrypted key wrappers, an authenticated encrypted inventory and encrypted file segments. It excludes the local device unlock secret. Import verifies the inventory, metadata and every segment before restoring into a vault with fresh identifiers, master key, file keys and a new device pattern. Save the new recovery key after restoration.
New recovery phrases preserve case, normalize Unicode with NFKC and collapse extra whitespace. Legacy hexadecimal keys remain supported. You can replace a vault’s recovery phrase in its settings after saving the new phrase. This replaces the current recovery wrapper; old backups and devices that have not synced can still hold the old wrapper. Changing a pattern or recovery phrase does not rotate the vault master key or revoke copies. If key material is compromised, move the files into a new vault with fresh keys.
Encrypted phone-to-phone migration
Phone transfer creates a portable encrypted copy with fresh vault identifiers, master key, file keys and stream headers. Its independent transfer secret cannot unlock the source vault, and the source recovery secret and device unlock secret are not included. The encrypted package and transfer secret must be delivered separately.
The receiving app authenticates the package and its file segments, then restores into a new vault with a new local pattern and recovery key. This works between iOS and Android without bridging their cloud accounts. The original remains on the old device; confirm the restored contents and save the new recovery key before deleting it.
Locking and session cleanup
The mobile apps lock immediately when backgrounded and after 60 seconds of inactivity by default. Each vault can select 30 seconds, 1 minute, 2 minutes, 5 minutes or 10 minutes. A shared vault uses the 60-second default. Exiting returns to the pattern screen and ends the decrypted session.
Locking cancels session work, clears decrypted metadata and search state, closes previews, removes temporary files and overwrites owned key buffers before releasing them. Temporary derivation keys are also cleared after use. Swift and JVM memory management, cryptographic libraries and media decoders may create copies; immediate erasure of every copy cannot be guaranteed.
iOS covers app-switcher snapshots with a privacy shield. Android uses the secure-window flag to restrict screenshots and recent-app previews. These platform protections do not prevent someone photographing an unlocked screen, and they do not retract files previously exported to another app.
Revault Cloud
Revault Cloud is an optional Pro storage provider for cross-platform sync. Encrypted segments and encrypted file metadata are linked to a pseudonymous billing installation. The service can observe storage identifiers, sizes, checksums, revisions and transfer activity, but receives no unwrapped vault key or recovery phrase. A separate random connection code authorizes storage access; connecting another device also requires the recovery phrase. Existing cloud data remains readable for recovery after Pro expires.
Native sharing transports and access controls
On iOS, a private, read-only CloudKit invitation places the encrypted snapshot in a separate sharing record hierarchy, outside the personal sync zone. Apple controls invitation access; the recipient still needs the separate decryption secret. CloudKit invitations do not enforce the server’s access-session count, fixed expiry or destruction timer. The owner can stop future CloudKit access.
Cross-platform shares upload encrypted parts to Revault’s sharing service. Independent random 256-bit read and management capabilities are stored as SHA-256 hashes. The website link carries the read capability in its fragment, not the decryption secret. Opening it deep-links to a shared vault and prompts for the sender’s secret; no personal pattern or existing vault is required. Personal vaults remain locked.
Controlled server shares enforce the sender’s maximum access sessions, fixed expiry within 30 days, revocation and optional export permission. A session is granted atomically and lasts at most 15 minutes, bounded by the share’s deadlines. An access counts when the session is granted, even if download or decryption fails. The viewer checks ongoing access and closes at its deadline.
SHA-256 checksums verify transferred parts, while authenticated encryption verifies their contents. When export is allowed, the viewer can save an encrypted .qvault copy that opens with the share secret. Disabling export removes that application action; it cannot cryptographically prevent screenshots or a modified client retaining plaintext. Deleting a source file does not revoke an independently created share.
Optional vault activity
Native audit logs are off by default and configured per vault on each device. The latest 500 local events are encrypted with the vault’s master key and a dedicated authenticated context. They exclude keys, patterns, file contents and other vaults’ data, do not sync, and can be cleared or disabled. They are not tamper-proof evidence. Failed unlocks are not assigned to a vault.
New controlled shares created with logging enabled retain up to 100 access-session timestamps on the sharing service. Only the management capability can retrieve them; the log contains no recipient identity or decryption secret. Disabling local logging affects future shares. Existing share logs retain their original setting until revocation or expiry and cleanup.
Optional encrypted break-in photos
Owners can enable Break-in Alerts separately for each vault on each device. After three unmatched patterns, the foreground app can capture a front-camera photo, subject to permission, camera availability and a one-minute cooldown. System camera indicators remain visible. The latest ten alerts are stored locally and never added to Photos or uploaded. An unmatched pattern does not identify a target vault, so each opted-in vault receives a separately encrypted device-attempt record.
A dedicated RSA-3072 public key wraps a fresh 256-bit AES-GCM key for each alert using OAEP with SHA-256 and MGF1-SHA-256. This permits encryption while the vault is locked. The corresponding private key is itself encrypted under that vault’s master key with a dedicated authenticated context. Only unlocking that vault can decrypt its photos. Alerts appear in its audit view independently of ordinary activity logging and can be cleared in Break-in Alerts settings. They are not tamper-proof evidence.
Safe Exit removes local access
One vault on a device can be designated for Safe Exit. Entering its pattern opens it normally while removing the other local vault records, encrypted chunks, device unlock material and queued changes. The app keeps a persistent local allowlist so sync cannot silently repopulate excluded vaults. Already in-flight encrypted transfers may still finish.
Native cloud copies and copies on other devices remain. Explicit recovery requires the excluded vault’s recovery key before a new local pattern is enrolled. An offline-only vault without a separate backup can be lost. This setting applies to the current installation, not every device using the same cloud account.
Safe Exit is not guaranteed forensic erasure or concealment. Flash storage, operating-system caches, backups and prior exports can retain traces. Removing app data or reinstalling can remove the local isolation boundary; cloud records may then be discovered again through the native cloud account. Only the recovery secret can unlock those records.
What remains visible
Encryption hides content, not all operational information. Local records and cloud providers can observe identifiers, record relationships, object counts, sizes, revisions, timestamps, encrypted key wrappers and stream headers. Identifiers use UUIDv7 and include creation-time information; they are not secrets. Apple or Google can associate native sync activity with the platform account.
Revault’s controlled sharing service can observe encrypted package sizes, part checksums, expiry settings, access-session counts and optional session timestamps, but not the separately delivered decryption secret. CloudKit sharing exposes invitation and participant information to Apple. Network and operational records can expose connection information. Revault does not provide anonymity or traffic-analysis resistance.
HTTPS protects network requests in transit. On-device authenticated encryption separately protects vault contents stored locally and in the cloud. Neither transport encryption nor ciphertext hides every fact about when, where or how much data is transferred.
Usage analytics
Enabled by default. Mixpanel receives feature-use events with a random analytics ID. Vault contents, names, patterns, keys and share secrets are excluded. Turn analytics off at any time for this browser or device.
Where the protection ends
An unlocked vault necessarily exposes decrypted information to its app session. Malware, a compromised operating system or app, someone viewing the screen, or an untrusted recipient can capture it. Device-only key storage is an additional boundary, not a guarantee against a fully compromised device. A predictable pattern is unsafe once its local secret is compromised.
Encryption does not prevent cloud deletion, ransomware, loss of a recovery secret, a provider withholding records or rollback of an entire previously valid encrypted state. Keep independent encrypted backups and verify recovery before removing an old device. Revocation cannot recall screenshots, exports or copies already retained by another person.
Revault has not undergone an independent security audit. These are descriptions of the implemented cryptographic design, not a certification or a guarantee against every intrusion.
Cryptographic references
NIST SP 800-38D — GCM authenticated encryptionRFC 8018 — PBKDF2RFC 5869 — HKDFExisting browser vaults
This reference describes the native apps. Existing browser vaults have a separate account, device-storage and web-cloud model. Browser-specific S3 uploads and browser share links are not native cloud sync. The browser account does not sign you into the mobile apps; use an encrypted backup and its recovery key to move existing browser data into a native vault.