The strongest security property enblob has is how little it knows. There is no enblob server holding your files, and in strong modes no key we could hand over even if we were compelled to.
AES-256-GCM, with the key derived on your machine. Ciphertext is what reaches your bucket.
No files, no keys, not even your bucket's name. Section 2 lists everything we do hold.
Run on AWS, Cloudflare, Backblaze, Wasabi or your own MinIO, and their durability and controls become yours.
Lose your key and the data is gone. One mode is deliberately weak. Section 7 spells out what we don't promise.
Most sync services ask you to trust a promise: that the company holding your files will behave well, resist a bad subpoena, and never suffer a breach that matters. Promises like that are only as durable as the company making them.
enblob is built so that the promise mostly isn't needed. Files move from your device to storage you own. There is no enblob storage tier they pass through and no copy retained on our side. When you use one of the strong encryption modes, the key that would decrypt them is generated on your machine and never transmitted to us — so "we would refuse to hand it over" is replaced by the stronger "we could not, because we do not have it".
The enblob client contacts our licensing server periodically to confirm your entitlement, check for updates, and fetch service notices. This is the complete list of what that exchange carries:
| We hold | We do not hold |
|---|---|
| Your email address | The contents of any file |
| A random installation identifier | Your file names, folder names, or directory structure |
| App version, operating system, processor architecture | Your encryption keys or passwords |
| First-seen and last-seen timestamps | Your bucket name, endpoint, region, or S3 credentials |
| A one-way fingerprint of each bucket configuration | Any index, thumbnail, or preview of your data |
The bucket fingerprint deserves a word. To count licence seats we need to tell your buckets apart, but we do not need to know what they are. So the client combines your endpoint, bucket name, and prefix locally, hashes them with SHA-256, and sends a short slice of the result. Your bucket's name and endpoint are never transmitted to us.
The honest limit: that fingerprint is an unsalted hash of a small, guessable input. It cannot be inverted, but somebody holding it who already suspected a particular bucket at a particular provider could hash that guess and check for a match. The design keeps your bucket's identity out of our database; treat it as minimisation rather than as an anonymity guarantee.
The client ships with no analytics SDK, no crash reporter, and no advertising identifier. What is listed above is everything.
Encryption happens on your device, before anything is uploaded. Your storage provider — and anyone who later obtains a copy of your bucket — receives ciphertext.
| Component | What we use |
|---|---|
| File contents | AES-256-GCM, an authenticated cipher: tampered data fails to decrypt rather than decrypting to something wrong |
| Keys from a password | Argon2id, memory-hard, tuned to 128 MiB and three passes to make brute-forcing expensive |
| Keys from a key file | 32 bytes from the operating system's cryptographic random source |
| In transit | TLS to your storage provider and to our licensing server |
File names and structure are protected too. enblob stores content by its hash, not by its path, so your folder layout is never the bucket's layout. Names, paths, and metadata live in encrypted state files, not in object keys. Someone reading your bucket sees opaque pack files, not a browsable copy of your documents folder.
Two small objects stay readable by design: the encryption configuration, which a new client must read before it can decrypt anything, and a change-detection marker whose contents are opaque. They reveal that a bucket is used by enblob and in which mode — not what is in it.
Encryption is chosen per bucket, at setup. The choice cannot be changed later without rotating the bucket, so it is worth a minute's thought.
| Mode | Protects against | The catch |
|---|---|---|
| Password | Anyone without your password, including your storage provider and us | Forget it and the data is unrecoverable |
| Key file | The same, with no password to type | You must back the key file up, and copy it to each device |
| Obfuscation | Casual inspection and automated content screening | Not real encryption — see below |
| None | Nothing | Your provider can read everything |
Obfuscation mode scrambles your files with a key embedded in the enblob binary. Because that binary is public, so is the key: anyone willing to pull it out can unscramble the data. It exists because it needs no password and still defeats automated screening by a provider — including machine-learning scans that have no specific support for enblob's format.
It will not stop a determined professional adversary, and it is not what protects you if your provider is breached by someone who knows what enblob is. For anything genuinely sensitive, use password or key-file mode. The app says the same thing at the moment you choose.
This is the scenario encryption is actually for, so it is worth being precise about what survives it.
| What happens | What it costs you |
|---|---|
| An attacker copies your entire bucket, in password or key-file mode | They hold ciphertext. Without your key it is not readable, and the key was never in the bucket or on our servers. |
| The same, in obfuscation mode | An attacker who knows enblob can recover the data. This mode is for non-sensitive content. |
| An attacker modifies objects in your bucket | Tampering is detected. AES-256-GCM authenticates every blob, so altered data fails to decrypt instead of silently becoming wrong. |
| enblob itself is compromised, or served a legal demand | What can be produced is the list in section 2. We cannot produce file contents or keys, because we never had them. |
| Your S3 credentials leak | Encryption still holds, but the holder can delete or overwrite your objects. Rotate the credentials, and keep versioning on. |
| Your device is compromised | Encryption does not help. The key is on that machine by necessity, so device security remains yours to maintain. |
Because the storage is yours, the security model is genuinely shared. This is not a disclaimer — it is the trade you make in exchange for us never holding your data.
| enblob's responsibility | Yours |
|---|---|
| Correct cryptography in the client, and encrypting before upload | Choosing a mode appropriate to how sensitive the data is |
| Never transmitting or storing your keys | Backing up your key file or password — there is no recovery |
| Collecting the minimum described in section 2 | Securing the S3 credentials the client stores locally |
| Securing our own licensing infrastructure | Bucket policy, access keys, IAM permissions, and public-access settings |
| Shipping updates when we find a problem | Versioning, lifecycle rules, and independent backups |
| Telling you plainly what each mode does and does not do | Keeping your own devices patched and access-controlled |
One point deserves emphasis because it is easy to miss: enblob is not a backup. Synchronisation faithfully propagates deletions and overwrites. If you delete a file on one device, enblob's job is to remove it everywhere else too. Keep independent backups, and turn on your provider's object versioning — it is the cheapest safety net available and it sits outside enblob entirely.
Because you bring your own storage, you inherit the security engineering of whoever you choose — and you can change your mind later. enblob works with any S3-compatible provider and ships presets for Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces, and self-hosted MinIO.
That means the physical security, redundancy, durability engineering, regional isolation, and compliance certifications of a major storage operator are available to you directly, rather than mediated by us. If you would rather trust nobody, run MinIO on your own hardware and the data never leaves your building. Either way the decision stays yours, and switching is a configuration change rather than a migration off a proprietary platform.
Whichever you pick, the sensible baseline is the same: a dedicated bucket, an access key scoped to that bucket alone, public access disabled, and object versioning enabled.
A security page that only lists strengths is not much use. These are the real limits, stated as plainly as we can.
If you have found a security issue, we want to hear about it before anyone else does. Email security@enblob.com with enough detail to reproduce the problem.
We will acknowledge your report, keep you updated while we work on it, and credit you when it is fixed if you would like us to. We will not threaten or pursue legal action against anyone who reports a vulnerability to us in good faith, gives us reasonable time to fix it, and does not access or destroy other people's data while investigating.
If you believe your own account has been accessed by someone else, contact security@enblob.com immediately.
Security reviews, procurement questionnaires, and awkward technical questions are all welcome — they tend to make the product better.