How Vault drops keep files unreadable, even to us
A plain-English walk through the cryptography behind Vault: where the key is made, where it travels, and what we can and can't see.
Most file sharing services encrypt your files, and then keep the key. That protects you from a stolen hard drive, but not from the service itself, a rogue employee or a legal demand. Vault drops are different: the key never leaves your hands.
The key is made on your device
When you turn on Vault, your browser generates a random 256-bit key using the Web Crypto API. It's never sent to Slingdrop.
Files are encrypted before upload
Each file is split into chunks and every chunk is encrypted with AES-256-GCM, an authenticated cipher that also detects tampering. File names and types are encrypted too, so our servers only ever receive opaque bytes and a size.
The key rides in the link
The share link looks like slingdrop.my/d/x7k2p9#k=…. Everything after the # is the fragment, and browsers never send fragments to servers. So the link carries the key to your recipient, but our servers never see it.
Want an extra layer? Add a passcode and the key in the link is itself wrapped with a key derived from the passcode (PBKDF2), so the link alone isn't enough.
Decryption happens in the recipient's browser
When someone opens the link, their browser reads the key from the fragment, downloads the ciphertext and decrypts it locally. Comments on Vault drops are encrypted with the same key, so the conversation is private too.
The trade-offs
Because we can't read Vault files, we can't generate server-side previews, run malware scans, or offer AI features on them, and we can't recover them if you lose the link. For contracts, IDs, medical records and source code, that's exactly the point.
Try it: turn on Vault in the composer, or read more on our Vault page.