Docs / Guides

Moving documents out of a Cryptomator vault

The usual way to move documents out of one encrypted vault and into another is to unlock the first one, copy everything to a folder, import the folder, and then delete it. That folder is a complete plaintext copy of everything you own, created by the act of taking security more seriously — and it outlives the copy, in the recycle bin, in whatever backup ran that night, in whatever indexed it while it sat there.

Keepsake for Windows reads the vault instead.

Point the importer at the vault

1. Open Keepsake and unlock your own vault.
2. Choose Import → Bulk import, then Browse.
3. Select the Cryptomator vault folder itself — the one containing vault.cryptomator and masterkey.cryptomator. Not a mounted drive letter; the folder as it sits in your cloud drive.

Keepsake recognises it as a vault rather than as a folder of files, and asks for the passphrase instead of scanning.

Enter the vault's passphrase

This is Cryptomator's password, not Keepsake's, and it is the only password belonging to another product that Keepsake ever asks you for. It is used on your computer to derive the key that unwraps that vault's own master keys, and for nothing else. It is not stored, not written into the vault, and not sent anywhere. Cryptomator is never contacted.

Read the result

Every document that came out is listed by its real name and the category it was filed under. Every one that did not is listed too, with the reason on the row — an unreadable name, a symlink, a chunk that failed its authentication tag. An importer that loses nine of ninety quietly leaves you believing all ninety arrived.

What happens on disk

One document at a time is decrypted into a single staging file under Keepsake's own application data, imported — which encrypts it into your Keepsake vault — and then overwritten and deleted before the next one starts.

So the most that is ever readable on disk is one document, for as long as one import takes, instead of all of them for as long as you forget. That is a smaller claim than never touches the disk, and it is the true one: reading text out of a scan and making a thumbnail both work from a path, and saying otherwise would be a nicer sentence about a product that did exactly the same thing.

On a solid-state drive, overwriting a file does not guarantee the old blocks are unreachable — that is a property of a controller we cannot see. What it does guarantee is that the file is not sitting there readable after the import, which is the failure that actually happens.

What it will not do

It never writes to your vault. Not a lock file, not a dirid fixup, not a modified timestamp. This is not a setting — there is no code in the reader that could write, open a socket, or make a network request, and the test suite fails if any of those appear in it. Your vault is byte-for-byte what it was when the import finishes.

It does not delete anything. When the import is done you still have a complete, working Cryptomator vault. Keep it as long as you like; keeping both for a while is the sensible thing to do.

It is not a sync. This is a one-time move. Documents you add to Cryptomator afterwards do not appear in Keepsake.

Limits, stated plainly

• Windows only. The web app and the Android app list this source and say it is desktop work. A browser has neither AES-SIV nor RFC 3394 key unwrapping, and Android hands an app one permission-scoped document at a time — a vault has to be walked as a whole, by following directory ids.
• Vault format 8 — what current Cryptomator writes. An older vault is refused by name and version rather than half-read; unlock it in Cryptomator once, which upgrades it, and try again.
• Symbolic links are skipped, and each one is named in the report. A link is a pointer to somewhere else, and importing it as a document would file the pointer, not the thing.
• A file that fails authentication is refused whole. Keepsake will not hand you the part of a document that survived and let it look complete.
• Vault passwords are not migrated. Your Keepsake vault has its own password, and this import does not change it.

Why Keepsake can read it at all

Cryptomator's vault format is published, and its apps are open source. That is genuinely to their credit, and it is the reason an importer like this can exist without anybody's permission or cooperation. We read that specification and wrote our own reader against it, tested against vaults built independently from the same document — so the reader and the thing it is tested with do not share a line of code, which is the only way agreement between them means anything.

Agreeing with a second reading of the same specification is still only that, so the suite also opens two vaults written by Cryptomator's own code: cryptofs, the library the Cryptomator desktop app uses to write vaults, taken out of a release archive whose GPG signature we checked before running any of it. Both cipher combos, and every test runs over all four vaults. That pair earned its keep the day it was added — real Cryptomator picks a different scrypt cost than our own test writer had, and it leaves a vault.cryptomator.*.bkup beside the config that our writer never made. A reader that had quietly assumed either would have worked perfectly on our tests and failed on your vault.

The honest edge of that: nobody sat in front of the Cryptomator desktop app and clicked through it to make those two. The app writes vaults with the same library, so the distance is small, and small is not none — so it is written down here rather than rounded off.

---