File 003 · The Blueprint

Every lock, labeled. Every gap, named.

A lock is only as strong as its weakest part, so here are all the parts: how the Windows and Android apps lock your files and notes, the key hierarchy, the file format, what we store, the attacks it’s built to withstand, and where the protection ends.

Last updated: September 2026 · Written by humans.

§ 01 · The Shape of the System

Locked before it’s stored. Wherever it’s stored.

The Windows and Android apps encrypt your files and notes on your device and keep the result where you choose: on the device itself, or in your own personal Google Drive, OneDrive or Dropbox. Our server has one job. It signs you in and keeps your account key in a locked form it can’t open. Your files, their names and your cloud logins never reach it. If you keep a vault in your own cloud, that provider holds ciphertext it can’t read, and still sees some metadata, which we list in full in § 07.

fig. 01 · data flowFiles and notes are locked on your device; your own cloud, if you add one, only ever gets ciphertext. Our server holds the locked key.

your deviceencrypts · decrypts
then, ciphertext only
your storagethis device · your cloud

your deviceopens the key
then, sign-in · locked key
our servercan’t open what it holds

§ 02 · The Key Hierarchy

Layered keys. Each one locks the next.

Reaching a file means getting through every key above it, and every key in that chain is created or opened on your device:

Your passphrase never leaves your device. There, it’s stretched with Argon2id (64 MiB of memory, three passes) into a passphrase key.
Your account key is a random 256-bit key, minted once when your vault is created. The passphrase key locks it with AES-256-GCM, and that locked copy is all we store.
Every file gets its own key, fresh and random, locked under your account key and carried in the file’s own header. No two files share key material.

Your Encrypted Notes live in the same vault, under the same account key.

fig. 02 · key hierarchyThe account key is only ever opened on your device. We store it locked, and can’t open it.

passphraseon your device
then, Argon2id + salt
passphrase keyon your device
then, unlocks
account keyrandom, 256 bits
then, locks
file keyfresh for every file
then, AES-256-GCM
.uvaultyour storage

Sign-in is a separate door. You sign in with Google or Microsoft, which proves who you are, not that you can open the vault. Changing your passphrase or removing an unlock method also asks for a one-way proof derived from your passphrase. The server can check that proof; it can’t turn it back into anything that opens your account key.

Key custody, place by place

Location	What’s there	How long
Our server	Your sign-in identity, your account key locked once per unlock method, the Argon2id salt and settings, a one-way passphrase proof, and your passphrase hint if you set one	Until you delete your account
Your device	The unlocked account key, and your files and notes while you work on them. On Windows and Android, optionally a copy of the account key sealed to the device’s secure hardware	While your vault is open; the sealed copy until you remove it
Your storage	.uvault files. In the cloud: encrypted objects under random names, one encrypted index per device, and your Encrypted Notes backups	As long as you keep them

Reset links are a way in. We don’t have one.

When encryption holds, attackers go after account recovery instead, posing as you to whoever can reset access. Here, no one can: no master key or recovery code exists, and support has no way in. The cost is real. Lose your passphrase and every other unlock method, and your files stay locked: we can’t open them, and neither can anyone else. Access comes from your key, never from a request.

One thing we do hold in the clear: the optional passphrase hint is stored in plain text. Anyone who read our database could read it too, so make it useful to you and useless to anyone else.

§ 03 · The .uvault File

A documented format, not a black box.

Every encrypted file, on your disk or in your cloud, is a .uvault file. The format is written down, and every Unlike Vault app reads and writes the same one.

AES-256-GCM in 4 MiB chunks. Each chunk carries its own authentication tag, and its position is bound into its nonce: a flipped bit, a reordered chunk or a truncated file fails loudly instead of decrypting to garbage.
A fresh key per file. A file from another account can’t be opened, and says so plainly instead of looking corrupted.
Authenticated metadata. The name, size and type at the moment of encryption travel inside the file, encrypted and tamper-evident.
No compression. Compressed length leaks information about the content, so we don’t compress.

fig. 03 · anatomy of a .uvault fileA 72-byte header, then authenticated 4 MiB chunks. Overhead: roughly 4 KB per GB.

UVLTmagic + version
then, then
file keylocked by your account key
then, then
metadataname · size · type, encrypted
then, then
chunk 1 … N4 MiB each, own tag

On your own disk, an encrypted file keeps its name with .uvault added, so anyone who can see the folder can see what you called it. In the cloud, names are hidden (§ 04).

§ 04 · Where Files and Notes Live

No files on our servers. One less target.

Unlike Vault doesn’t host files. You choose where each vault lives:

This device. The Windows and Android apps encrypt the files you choose in place, in the folders you already use: the encrypted copy is written and checked before the original is removed.
Your own cloud. Connect a personal Google Drive, OneDrive or Dropbox and the vault becomes one folder in it. On Google Drive the app can only see the files it created; on OneDrive the vault lives in Apps/Unlike Vault; on Dropbox, in the app’s own folder. Nothing else in your storage is read, touched or encrypted in place.

fig. 04 · a cloud vault, as your provider sees itRandom names in a flat folder. Your real names and folders live only inside the encrypted indexes.

Unlike Vault/the one folder the app works in
vault.jsonplaintext marker · no user data
manifests/<id>.uvaultone encrypted index per device
objects/<id>.uvaultyour files · random ids · no folders

In a cloud vault, renaming or moving a file rewrites only your encrypted index; the file underneath never moves. When two of your devices change things at once, their indexes are merged, never overwritten, and an index served back in an older state is refused rather than trusted.

Encrypted Notes live inside the vault too, in both apps: rich text, checklists, colors, pins, archive and search, locked like your files. With a cloud connected, they’re backed up to it and restored from it, still encrypted.

On the web, Unlike Vault is browser-based file encryption: choose one file or many, and the encrypted result is saved where you choose. No folders, no cloud, no Notes, on purpose.

§ 05 · One Key, Several Locks

Open it the way you like. Lose one, keep the key.

Your account key can be locked more than once, one locked copy per unlock method, so you choose how to open it day to day:

Your passphrase. Works everywhere. It’s the one you must not forget.
A passkey (web). A fingerprint, a face scan or a physical security key; the passkey’s own secret locks a copy of your account key. You add a passkey to an account — it never creates one.
Your device’s secure unlock (Windows and Android). Windows Hello with the TPM, or the Android Keystore with your phone’s biometric unlock. That copy is sealed to the device’s hardware and opens nothing anywhere else.

Your passphrase is the load-bearing wall. Everything we store is guarded by it: a stolen copy of our database can only be attacked by guessing your passphrase, and Argon2id makes each guess cost 64 MiB of memory and three passes over it. Choose something long that nobody could guess, and keep it somewhere only you will find it.

§ 06 · Threat Model

Each attack, and what stands in its way.

#	Property	Mechanism
T1	A database leak opens no files	Someone holding the entire database gets locked keys and a one-way passphrase proof, keyed with a secret stored outside the database. Nothing on our side can open a file.
T2	A curious storage provider can’t read your files	It holds ciphertext under random names. Your filenames and folders exist only inside encrypted indexes.
T3	A tampering provider gets caught	Every chunk and every index is authenticated. A changed byte fails to decrypt, and an index rolled back to an older state is refused.
T4	A stolen device doesn’t hand over the key	The device’s copy of your account key is sealed to its TPM or Keystore. Off that device, it opens nothing.
T5	A stolen session can’t change the locks	Changing your passphrase or removing an unlock method needs proof derived from your passphrase, which a session alone doesn’t have.

§ 07 · Where Protection Stops

What stays outside the lock.

Known exposures · listed in full

In a cloud vault, your storage provider still sees metadata. How many encrypted objects there are, roughly how big each one is, and when anything is written, renamed, deleted or downloaded. The size of the encrypted indexes hints at how many devices you use and how many items you keep. It sees when the vault was created, the account and IP address that connect, and a small plaintext vault.json marker that says the folder belongs to Unlike Vault. It doesn’t see your filenames, your folders or a byte of your content.

Your sign-in provider knows when you sign in. Google or Microsoft can see that you use Unlike Vault and when you authenticate. That’s what signing in with them means.

Local files keep their names. An encrypted file on your disk is still called tax-return.pdf.uvault. Anyone who can see your folders can see what you named things.

Only the files you choose are encrypted. Unlike Vault doesn’t encrypt an existing cloud account in place. Everything outside its folder stays exactly as it was, readable included.

Deleting isn’t shredding. When a file is encrypted in place, the original is removed once the encrypted copy is verified. On modern drives, a deleted file can leave traces that forensic tools may recover.

Whoever controls your sign-in can delete your account. Someone who takes over your Google or Microsoft account can’t open your files, but they can delete your Unlike Vault account, and the locked keys we hold with it. Your encrypted files stay where they are, and you may be left with nothing that opens them. Guard that sign-in like it matters, because it does.

A device that’s already compromised is out of reach. Malware running as you can read what you can read and click what you can click. No encryption app changes that.

Lose every unlock method, and you’re locked out too. There’s no reset for an attacker to abuse, which means there’s none for you either. Put your passphrase somewhere safe before you need it.

A threat model is only useful if its gaps are in it. These are ours, so you can plan around them.

§ 08 · What It’s Made Of

Well-studied primitives. No homemade ciphers.

Layer	Component	Why it’s there
File encryption	AES-256-GCM · 4 MiB chunks	Authenticated encryption, each chunk bound to its place in the file.
Key derivation	Argon2id · 64 MiB, t=3, p=1	Each passphrase guess is slow and memory-heavy, even for someone holding our database.
Key separation	HKDF-SHA256	One-way derivations: nothing we hold runs backwards into a key.
Device unlock	TPM · Android Keystore	The device-sealed key opens nothing off the device.
Passkeys (web)	WebAuthn with PRF	Unlocking needs the passkey itself, and we verify it before anything is released.
Apps	Rust core + Tauri	One shared core for Windows and Android: the same format and the same lock on both.
Web	WebCrypto	Browser-based file encryption in the same .uvault format.

Published standards for every primitive, with the threat model and the file format written down beside them. We didn’t invent a single primitive, and that’s deliberate.

§ 09 · Roadmap

Wider reach. The same lock.

Windows and Android, side by side. Both apps are in development and launch with the same features: files encrypted in place, local vaults, Encrypted Notes, optional cloud vaults and device unlock.
More storage providers. Personal Google Drive, OneDrive and Dropbox come first. More are coming soon, and only where the provider lets the app work inside its own folder and nowhere else.
Secure Share. A separate Adamanture product for sharing files, coming soon. Unlike Vault itself doesn’t share files.
The web stays small. In the browser, Unlike Vault encrypts and decrypts files, and that’s all. It’s a deliberate boundary, a smaller surface rather than a missing feature.

Still have a question about the design? The FAQ goes further, and Compliance & Trust maps each security control to the part of this page that documents it.

Try 30 Days Free — No Card Compliance & Trust →