Encryption on buckets.ninja: three layers, and which one to use
Every object you store on buckets.ninja is encrypted at rest by default. But "encrypted" can mean several very different
things depending on who holds the keys — and that difference is the whole privacy story. There are three layers you can
use, each protecting against a different threat. This guide explains what each covers, what it does not, and how to turn
on the strongest one.
The three layers at a glance
| Layer | Who holds the key | What we can see | Set-up | | --------------------------------- | ----------------------- |
------------------------------------------------ | ---------------------- | | 1. SSE-S3 (default) | We do | Your
plaintext, in transit and in memory | None — always on | | 2. SSE-C | You send it per request | Your plaintext briefly,
while we encrypt/decrypt | Per-request header | | 3. Client-side (rclone crypt) | Only you, ever | Ciphertext only —
nothing readable | One-time rclone config |
Layer 1 — SSE-S3 (server-side, our keys)
On by default, zero configuration. Every object is encrypted on disk with keys we manage.
- ✓ Data at rest is encrypted; satisfies compliance and "encrypted storage" requirements.
- ✗ We manage the keys.
Layer 2 — SSE-C (server-side, your key)
You send your own AES-256 key with each request. We use it to encrypt or decrypt the object and then discard it
immediately — it is never written to disk.
- ✓ On disk your data is ciphertext under a key we do not keep.
- ✗ The key travels with every request.
SSE-C is a good fit when your tool manages the key for you and you want the server to do the work. Most rclone and
aws-cli users are better served by Layer 3, which never sends a key at all.
Layer 3 — Client-side encryption (the strongest)
Encrypt before the data leaves your machine, using rclone crypt. We only ever receive ciphertext, so we literally cannot
read your data — filenames included.
- ✓ The strongest guarantee: we only ever see ciphertext. This is the configuration to use if you want "not even the
provider can read this".
- ✗ If you lose your passphrase, the data is irrecoverable. We cannot reset it.
Setting it up with rclone
Start from the ready-made config you can download in the panel (Buckets → Download rclone.conf) — it already contains
your [buckets-ninja] remote. Then:
1. Generate an obscured passphrase. This is rclone's storage format, not extra security — keep the real passphrase safe
yourself:
rclone obscure "a long passphrase you will not lose"
2. Add a crypt remote that points at one of your buckets:
[buckets-ninja-crypt]
type = crypt
remote = buckets-ninja:PREFIX-yourbucket
filename_encryption = standard
directory_name_encryption = true
password = <output of rclone obscure>
Replace PREFIX-yourbucket with your bucket name (your account prefix is shown in the panel). The commented block at the
bottom of the downloaded rclone.conf has this ready to uncomment.
3. Use the encrypted remote for uploads and downloads:
rclone copy ./private-folder buckets-ninja-crypt:
Everything written through buckets-ninja-crypt is encrypted locally first. If you list the same bucket through the plain
buckets-ninja remote you will see only scrambled filenames and ciphertext — exactly what we see too.
Which layer should I use?
- Just want encryption at rest / compliance? You already have it (Layer 1), nothing to do.
- Want us unable to read your data? Use Layer 3, client-side rclone crypt.
Keep your passphrase. With client-side encryption there is no recovery path. Store the passphrase in a password manager
before you upload anything you cannot afford to lose.
