Protection starts before upload
File contents, filenames, MIME types, thumbnails, vault names, and folder names and structure are encrypted on your device before they are uploaded. The service stores ciphertext and wrapped keys. An intruder who obtains only those stored records does not obtain the plaintext vault key, the device secret, or your recovery key.
This assumes that the browser, operating system, delivered application code, and random number generator are trustworthy when you create or unlock a vault. Encryption at rest cannot protect an unlocked vault from malicious code running on your device.
Independent keys for every vault
Each vault starts with a randomly generated 256-bit AES master key. The key is generated by the browser’s cryptographic random number generator, rather than being derived directly from your gesture. Separate vault keys limit the effect of a single vault key being disclosed.
A device pattern combines the ordered dot sequence with a random 256-bit device secret. PBKDF2 with HMAC-SHA-256, a fresh 128-bit salt, and 600,000 iterations derives a 256-bit wrapping key. AES-256-GCM then encrypts the master key under that wrapping key. The service receives the encrypted wrapper, its salt, and public derivation parameters. The device secret remains in this browser’s local IndexedDB database.
Patterns use only a 5 × 5 grid and at least six distinct dots. Previous pattern formats are unsupported. Existing vaults need their recovery keys to enroll a new pattern. Grid size is not a promise of password strength: predictable gestures are still easier to guess. The device secret adds protection against someone who has only the server records, but it is not a hardware-backed key. Someone who copies both the local secret and wrapper can attempt offline pattern guesses.
Passkeys authenticate your account using public-key challenge responses. Account authentication does not derive a vault key or decrypt your files. A valid account session and a successful vault unlock are separate requirements in the normal application flow.
| 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 | 192 random bits, displayed as six groups of hexadecimal characters |
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
File contents use the AES-256-GCM-HKDF-SHA-256 streaming construction described by Tink, implemented using browser cryptographic primitives. Each new file stream has a 40-byte header containing its length marker, a random 32-byte salt, and a random 7-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 application processes files in bounded segments of approximately 5 MiB. Segment positions, the final-segment flag, and expected byte lengths make swapped, altered, or truncated segments fail verification. Downloads authenticate each segment before releasing it; an error late in a stream can leave an incomplete download, so successful completion matters. Upload retries reuse already encrypted bytes rather than encrypting new content with the same segment nonce.
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.
Recovery is a second path to the same key
A recovery secret is generated from 24 random bytes, giving 192 bits of random input. It independently derives a wrapping key using PBKDF2-HMAC-SHA-256 and its own salt, and encrypts the same vault master key with AES-256-GCM. Anyone who obtains the recovery secret and a copy of the encrypted vault can decrypt that vault.
The recovery secret is displayed during setup and is not stored by the service in plaintext. Keep it separately from your encrypted files. Clearing browser data removes the device secret; recovering access requires your account’s encrypted cloud copy and the recovery key, or an exported encrypted backup and its recovery key. There is no provider-held master decryption key.
A recovery kit contains a secret and key wrappers, but no file contents. An encrypted backup contains an authenticated inventory and encrypted file segments, without the browser’s device secret. Import verifies the encrypted data and creates a new vault with new identifiers and keys.
Changing a pattern replaces this device’s wrapper. It does not rotate the vault master key, revoke another device, invalidate old backups, or change an existing recovery secret. If a vault key or recovery secret is compromised, move the data into a new vault with fresh keys.
Native shares use independent encryption
Mobile shares wrap selected file-version keys under a fresh share key by default, reusing encrypted file bytes. Optional extra isolation re-encrypts the files. Source vault keys stay private. Identical ciphertext can correlate shares; neither mode can recall a recipient’s saved copy.
iOS can place this ciphertext in a separate CloudKit record hierarchy with a private, read-only invitation. It does not share the vault’s sync zone. Cross-platform native shares use bounded server parts with SHA-256 checksums. Independent random 256-bit read and management capabilities are stored as hashes on the server. The decryption secret is passed separately and never uploaded. Controlled shares expire at the sender’s chosen time, within 30 days. The service atomically counts access sessions and enforces the chosen maximum, expiry and revocation. A download session lasts at most 15 minutes and never beyond share expiry.
Receivers authenticate every encrypted segment and open an isolated shared vault with the sender’s separate secret. No account, personal vault or pattern is required. Personal vaults remain locked. When export is allowed, recipients can save an encrypted .qvault copy that opens with that share secret. Otherwise, export controls are absent. The temporary session validates ongoing access. These are application controls: screenshots, modified clients and retained copies cannot be prevented cryptographically. Shares are snapshots without ongoing source updates. Unrestricted CloudKit invitations do not enforce access counts or automatic expiry; access lasts until the owner stops sharing. Removing an original does not revoke its separate share, and no revocation can recall an already retained copy.
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.
Encrypted uploads to your own bucket
A vault’s Storage settings can connect this browser directly to a user-specified S3-compatible HTTPS endpoint. Selected device files are encrypted locally using the same file construction. Each becomes a separate, portable .qvault object containing an authenticated encrypted inventory and wrapped vault keys. Random object names avoid exposing the original filenames. Restore requires the downloaded object and the vault recovery key.
The endpoint configuration and credentials are encrypted under the vault master key with a dedicated authenticated context and kept in this device’s IndexedDB. They are not synced or sent to Revault’s API. Request signing uses AWS Signature Version 4, HMAC-SHA-256, and a hash of each bounded request body. Eight-MiB multipart parts carry already encrypted bytes directly to the storage provider. Bucket access remains governed by that provider’s permissions and CORS policy.
The provider can see access-key identifiers, object paths, byte sizes, upload times, and connection information. Keep the bucket private and its credentials scoped to the required operations. Uploaded objects are independent of Revault cloud sync and sharing. Locking or cancellation attempts to abort unfinished uploads; tab closure or loss of connectivity can leave orphaned parts, so configure an incomplete-upload lifecycle rule. Safe Exit removes other vaults’ local storage credentials but does not delete objects from their buckets.
Safe Exit removes local access
You can designate one vault in this browser as a Safe Exit vault. Entering that vault’s pattern opens it normally, without a trigger confirmation or completion notice. Other vaults’ local snapshots, encrypted chunks, device secrets, and queued changes are removed. Unsynced data can be lost.
A persistent local boundary prevents those vaults from being automatically listed or restored through sync on this browser. Their encrypted cloud copies and copies on other devices remain unchanged. Recovery is explicit, one vault at a time, and requires that vault’s recovery key before a new device pattern can be enrolled.
This is local access removal, not guaranteed physical erasure or forensic concealment. Browser profiles, filesystem snapshots, prior downloads, screenshots, service records, and another device can retain evidence. Clearing this browser’s local data also clears the local isolation boundary; a fresh installation can list the account’s cloud vaults again after authentication.
What remains visible
Encryption protects content, not every fact about storage. The service can observe account associations, random object identifiers, object counts, byte sizes, revisions, timestamps, encrypted wrappers, stream headers, and request activity. Network and operational records can reveal connection information. This is not an anonymity system and does not provide traffic-analysis resistance.
Transport encryption protects requests in transit when the application is served over HTTPS. That is separate from the client-side encryption which keeps stored file contents encrypted at the service.
Where the protection ends
Private browsing usually deletes local storage when the private session ends. A persistent-storage request does not make an incognito session permanent. Synced cloud copies remain, but local patterns, unsynced changes, cached files, and Safe Exit settings can be lost. A new private session needs account access and your recovery key to enroll a new pattern.
The application drops its in-memory vault key reference and revokes private preview URLs when locked. It automatically locks when hidden or after five minutes of inactivity. Native apps also lock when backgrounded, remove temporary previews, and wipe owned key buffers when operations finish. Browser, Swift and JVM memory management cannot guarantee immediate erasure of every key copy or decoded media buffer.
Malware, an unsafe extension, compromised application code, or someone viewing an unlocked screen can capture plaintext and secrets. Encryption cannot prevent account denial of service, deleted cloud objects, ransomware, loss of a recovery secret, or a service withholding data. Keep a separate encrypted backup and protect the device itself.
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.