Keepsake vs Cryptomator

What Cryptomator is, and what it is excellent at

Cryptomator encrypts a folder file by file, so that the folder can then sync through any provider you like — Drive, Dropbox, OneDrive, pCloud, WebDAV, a NAS. You unlock the vault, it mounts as a drive, and everything written into it is encrypted on the way out.

The design is right, and it is the same shape we chose. Per-file encryption rather than one large container means sync moves only what changed. Filenames are encrypted with AES-SIV and the directory tree is indirected through directory IDs, so the provider sees meaningless names in a meaningless shape. The content cipher is AES-256 in SIV_GCM (or SIV_CTRMAC on older vaults), which is authenticated — a tampered file fails rather than decrypting to something wrong. The masterkey is wrapped with scrypt at N=32768, which is memory-hard. It is GPLv3, the source is public, the crypto libraries have been audited by Cure53, and the desktop app is free with unlimited vaults.

If your requirement is "encrypt a folder in my own cloud, spend nothing, read the source", use Cryptomator. We would rather say that than win somebody over for a job we are not better at. The rest of this page is about the other job.

The crypto is a tie, and we are going to say so

It would be easy to write a page implying our encryption is better. It is not, and the first competent reader would say so.

Cryptomator's content cipher is AES-256 in SIV-GCM, which is authenticated encryption with associated data, exactly as ours is. Its masterkey is wrapped with scrypt, a memory-hard KDF from the same family of choices as our Argon2id. Filenames are encrypted with AES-SIV using the parent directory ID as associated data, which is a careful piece of design and closes the same hole our name-free blobs close. Per-file encryption is the correct shape for cloud sync, which is why both products landed on it.

On confidentiality at rest, on key derivation, on sync efficiency and on bring-your-own-cloud, this comparison is a tie. On open source and independent audit, we lose. Whatever case there is for Keepsake against Cryptomator has to be made above the encryption layer, and that is where the rest of this page makes it.

Where Cryptomator genuinely beats us

Copied from our own planning document without softening, and each one carries a row in the claim ledger:

• It is free, and on the desktop it is free and unlimited against our five-document free tier. If the requirement is strictly "encrypt a folder, no money", Cryptomator is the answer and we will not pretend otherwise.
• Its source is public and ours is not. Someone who wants to read the cryptography can read theirs. We publish the vault format byte for byte and a reproducible build; that is evidence of a different and weaker kind.
• It has been audited by Cure53. We have tests. A test suite is not an audit and we will not let ours be read as one.
• Native on macOS and Linux. There is no native macOS or Linux build of Keepsake and none in progress; our answer there is the installable web app, which is a full vault peer and is still not the same thing.
• Ten years of public scrutiny. Only time fixes that, and it is not for sale.

What an encryption layer cannot know

Cryptomator cannot tell you that your passport expires in six weeks, find the policy number you half-remember, pull the fields off an insurance schedule, file an attachment out of an email, or let your executor open the vault when you cannot. That is not a backlog — a FUSE mount has nowhere to put that knowledge. It sees files, and it has deliberately made even their names unreadable.

The irony a long-time user will recognise: the better the filename encryption works, the less you can find. Search on the provider's side is impossible by design, and search on your side is whatever your operating system can do with a mounted drive — which, on an encrypted vault you unlocked ten seconds ago, is usually nothing useful.

Keepsake reads each document on the device that holds it: eleven document types recognised, fields and numbers extracted, OCR for scans and photographs, ranked retrieval across the lot, three levels of expiry warning with country renewal checklists, and an answer that quotes the line it came from.

A mount is a plaintext surface

While a Cryptomator vault is unlocked it is a drive, and that is the point of it — every program can open your files without knowing anything about encryption. Read the other way, the same sentence says: any process running as you can read all of it, thumbnailers write previews of it, antivirus reads it, and another cloud client can pick files up off it.

We measured the first of those rather than asserting it. A Cryptomator vault was unlocked and mounted with Cryptomator's own signed CLI, and a script holding no passphrase walked the drive and read all 7 documents, 99,816 bytes, out of it. That is the whole claim, and it does not depend on any setting.

The search indexer is a different question, and the measurement came back against the tidier version of our story, so here it is. With the vault mounted over WebDAV, a document planted inside it contributed nothing to the Windows Search index — not its text, not even its file name — while an identical document in an ordinary folder was fully indexed within minutes. Windows does not index network locations by default and a WebDAV mount is one. So “a mounted vault gets indexed” is not true of that mounter, and we are not going to print it. What we have not measured is Cryptomator's default mounter on Windows, which is WinFsp and presents a local volume; nothing here describes that case and nobody should read it as if it did.

Careful users mitigate the rest, and the mitigations are real: keep the vault locked except when you are using it, exclude the mount point from search indexing and from other sync clients, prefer the WebDAV mount to a drive letter where your platform allows — which is the one our own measurement supports — and do not leave it unlocked overnight. None of that is required with Keepsake, because there is no mount to exclude: there is no filesystem-mount code in it on any platform.

What Keepsake does not get to claim, because we measured it: no plaintext on disk at all. Opening a document in another application writes a temporary file and deletes it when the viewer closes, since handing a PDF to Acrobat means handing Acrobat a path. The measured difference is scope and duration — one document while you are looking at it, against every document in the vault for as long as it is unlocked — and that is the claim, rather than the tidier one.

Two devices, one document, no signal

On upload cost there is nothing between us, and a comparison that invented a difference here would be worth nothing. Both designs move a document rather than a volume. Measured on both sides now: editing one 200 KB document — one kilobyte changed in the middle of it — costs 200.3 KB on Cryptomator and 200.2 KB on Keepsake, and neither figure grows with the size of the vault. The Cryptomator figure comes off a copy of a real vault, mounted by Cryptomator’s own signed command-line tool: the document was edited through the mount, and the encrypted files underneath were counted before and after. Exactly one changed; nothing was added, removed, or left behind.

That Cryptomator figure used to read 224.3 KB here, worked out from the published format rather than measured, and it was wrong — 12% too high, against them. The arithmetic had rounded the last chunk of the document up to a full 32 KB when a part-used chunk costs only what it holds. We publish the correction with the number because the number was ours: a figure derived from a specification is a prediction, and this one was repeated on this page for weeks before anyone checked it against a disk.

The difference is what happens when two devices edit the same document while both are offline, which on a household vault is a Tuesday rather than an edge case. Cryptomator stores one file per document, so two versions of that file arrive at the provider and the provider does what it always does: it keeps both, and names the second one after itself. That copy is encrypted under a name the vault does not recognise, so it does not appear in the vault at all — you are left with one of the two edits and a file you cannot see, let alone read.

Keepsake's unit of conflict is a field, not a file. Measured in the benchmark: device A sets an expiry date, device B sets a title, both while offline, both sync — both edits survive, a third field neither touched is unchanged, both devices reach the same state, and there are no conflict copies in the cloud folder. The command is dotnet run --project tools/compare/SyncCost; it runs the shipped sync engine against a real vault and the transcript is in tools/compare/reports/.

What is still not measured: the conflict itself. The paragraph above describes what a cloud client does with two versions of one file, which is the client’s behaviour rather than the vault’s, and observing it needs a real provider and two machines. It is written here as an expectation and it is marked as one in the report; no number and no screenshot of it appears anywhere on this site until somebody has watched it happen. The upload cost beside it is a different matter — that one has now been read off a disk.

There is no plan for afterwards

A Cryptomator vault has two ways in: the password, and the masterkey file that the password wraps. If both are lost, the vault is gone. If you are gone, the vault is gone with you — there is no second holder, no split secret, no escalation, no way for a partner or an executor to reach the documents they now need most.

The Legacy Access Kit is our answer: a 2-of-3 Shamir split you print and distribute, a check-in schedule that escalates on its own if you stop answering, and a rehearsal you can run today to prove it works. Household access is the same story on a shorter timescale — five roles, key-based, no server anywhere. Cryptomator's org answer is Hub, which is a subscription and a server you run; ours needs neither.

Keepsake reads your Cryptomator vault

This is the part we would like you to test rather than believe. Keepsake's Windows app imports a Cryptomator vault directly: you point it at the vault directory, type the vault password, and it decrypts the masterkey, walks the encrypted directory tree, decrypts the filenames and brings your documents in — where they are then typed, OCR'd, and given their expiry dates.

• It is read-only. Nothing is written to the source vault, ever. That is asserted by the test suite, not promised in a sentence.
• It refuses rather than guesses. An unknown vault format version stops the import instead of being interpreted hopefully, and every file that is skipped is reported to you by name — because dropping four of somebody's forty documents quietly leaves them believing all forty arrived.
• Your vault still works afterwards. Nothing is moved, nothing is removed, and Cryptomator opens it exactly as before. Running both is a perfectly sensible arrangement: the vault for the bulk archive, Keepsake for the paperwork with dates on it.

The steps, with what to expect at each one, are in importing a Cryptomator vault. It is also the plainest demonstration of the thing we ask people to believe about us: a published format means somebody else can read it. Cryptomator's is published, so we did.

Who should use which

• Stay with Cryptomator if the job is encrypting a folder in your cloud, if free and unlimited matters, if you want to read the source, or if you are on macOS or Linux and want a native app.
• Use Keepsake if the job is the paperwork: documents that have dates, that need finding, that live on a phone, that somebody else may have to open.
• Use both — which is what we would actually suggest to someone already running a vault they are happy with. The importer is read-only precisely so that this is not a decision you have to make before trying it.

The honest verdict

Cryptomator is a good product built by people who understand the problem, and if we ever publish a page implying its encryption is weak, that page is wrong. The honest case is narrower and, we think, more useful: an encrypted folder solves confidentiality and stops there, and household paperwork needs the four things it cannot have — knowing what a document is, knowing when it expires, letting someone else in, and still being openable when you are not around. The importer is read-only so that you can check that case against your own vault without giving anything up.