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.