Your files are encrypted before they leave your browser
When you upload a file to Rabbithole, it never leaves your device in plaintext. The encryption happens entirely in your browser — your canister only ever sees sealed data.
What this means for you
- Nobody can read your files — not even the Rabbithole team
- Even the blockchain nodes can't decrypt your data — they store only encrypted fragments. While IC nodes can technically access canister memory, all your data is encrypted with vetKeys before it reaches the canister. Without the threshold key derivation (which requires your identity), the stored data is indistinguishable from random noise
- Hardware isolation is coming — the Internet Computer is developing TEE support based on AMD SEV-SNP, which adds hardware-level memory isolation so that even node operators cannot access canister memory. For Rabbithole this means double protection: vetKeys encryption + hardware isolation
- If Rabbithole shuts down — your encrypted data persists on the blockchain
- Each fragment is independent — a problem with one doesn't affect others
How encryption keys work
Your encryption key is derived from your Internet Identity using vetKeys — threshold cryptography built into the Internet Computer.
- No passwords to remember or lose
- No key files to back up
- The key is computed on-demand by 13-34 independent nodes working together
- No single computer in the network knows your full key
Think of it like a vault that only opens when enough independent guards agree it's really you. No single guard can open it alone.
Unique key for each file
Unlike services that use one master key for everything, Rabbithole derives a unique encryption key for each file using a concept called derivation ID:
Each file has a unique derivation ID — the same master secret produces a completely different key for each file. This means:
- Compromising one file's key doesn't reveal keys for other files
- Keys are deterministic — the same derivation ID always produces the same key, so you can re-derive them on demand without storing key material
- The master secret never exists in one place — it's always split across multiple nodes
Sharing encrypted data
When you share storage with another user, the sharing happens through access control at the canister level, not re-encryption:
The key insight: encryption keys are bound to file IDs, not user IDs. The canister decides who is allowed to request a key for a given file. When access is granted, the new user can derive the same file key — no re-encryption needed.
This design means:
- Adding users doesn't require re-encrypting all data
- Revoking access is handled at the canister level — the canister simply stops granting key derivation requests
- The owner controls everything — only the canister controller decides who gets access
The cost of encryption
vetKey derivation costs approximately $0.035 per operation. This is paid from your canister's compute cycles — not from your wallet. A single derivation covers all operations in a session.
Technical Details
Click to expand technical details
Algorithm
- AES-GCM (Galois/Counter Mode) — authenticated encryption
- 12-byte random IV per fragment
- 16-byte authentication tag per fragment
- Total overhead: 28 bytes per fragment
Fragment sizes
Large files are automatically split into ~1.9 MB fragments. Each fragment is encrypted independently with a unique random initialization vector. The encrypted fragments are well within the canister's 2 MB chunk limit.
Key derivation flow (vetKD protocol)
Transport key mechanism: The browser generates an ephemeral key pair for each key request. Each IC node encrypts its partial key contribution under this transport public key. Even if all network traffic is observed, the derived key remains secret — only the browser holding the transport secret key can decrypt the partial contributions.
Cryptographic primitives
Security properties
- Confidentiality — AES-GCM encryption with unique IV per fragment
- Integrity — authentication tag detects any tampering
- Threshold key derivation — 13-34 nodes must cooperate to derive the key
- Fragment isolation — each fragment encrypted independently
- Per-file keys — unique derivation ID per file
- Transport encryption — ephemeral keys protect key material in transit
Staging mechanism
To prevent data corruption during upload, new files are marked in a "staging" area until all fragments are uploaded and verified via SHA-256 checksum. Only then does the file become visible in your file system.