What Etebase Actually Encrypts (and What It Doesn't)

SilentSuite is an open-source, end-to-end encrypted alternative to Google Calendar, Contacts, and Tasks, built on the Etebase protocol. “End-to-end encrypted” is a claim that deserves detail. This post walks through what Etebase actually encrypts, field by field, and what it deliberately leaves visible to the server. The honest answer is that the contents of your data are encrypted and a thin layer of metadata is not, because the server needs that metadata to sync at all.

If you have read our threat model post, this is the cryptographic detail behind it. Where that post drew the line, this one shows you exactly where the line sits in the data.

What does Etebase encrypt?

Etebase is built around two kinds of objects: collections and items. A collection is a calendar, an address book, or a task list. An item is a single event, contact card, or task inside one. Both are encrypted on your device before they reach a SilentSuite server, using XChaCha20-Poly1305 for the data and Argon2 to derive your keys from your password (the same primitives libsodium provides). The server stores the result and never holds the keys.

Concretely, the following are encrypted client-side:

• Item content. The body of every event, contact, and task. The title of a meeting, its time, location, attendees, notes, and the full vCard of a contact, all of it is ciphertext to the server.
• Item metadata. Per-item fields like the item's own name and type are encrypted too, not just the payload.
• Collection metadata. The name of a calendar (for example “Therapy” or “Job search”), its description, and its color are encrypted. The server does not know that you have a calendar literally called “Therapy.”

This matters because a calendar's name can be as revealing as its contents. A provider that encrypts events but leaves collection names in plaintext has not actually protected you. Etebase encrypts the labels, not just the contents under them.

What does the server still see?

Here is the part that “zero-knowledge” marketing usually glosses over. The server is not blind. To synchronize devices, resolve conflicts, and run accounts, the server has to see some structural facts. Etebase minimizes these, but it does not pretend they are zero.

• That collections exist. The server knows your account has some number of collections, even though it cannot read their names or contents. It can tell you have, say, three calendars and two address books.
• Item existence and count. The server can see roughly how many items a collection holds. It knows a calendar has hundreds of events without knowing what any of them say.
• Timestamps and revisions. Each change creates a new revision, so the server sees when items are added or modified. It can observe that your account had sync activity at 7am on a Tuesday.
• Sync tokens and structure. The server tracks the chain of revisions per collection so devices can catch up incrementally. That chain is structural data, separate from content.
• Account-level facts. Your login identifier and the existence of your account are known to the server, because you have to authenticate to sync.

So the server can infer activity patterns. It cannot infer meaning. It might see that a collection gained ten items last week; it cannot see that they were ten oncology appointments. The gap between “something happened” and “here is what happened” is exactly the gap end-to-end encryption is for.

Which fields can the SilentSuite server see?

For readers who want the precise picture, here is what is encrypted and what is visible, laid out plainly.

How does the encryption actually fit together?

Etebase uses a layered key model rather than encrypting everything directly with your password. It is worth understanding the shape, because it explains several properties that surprise people.

1. Your password derives a login key and a master key via Argon2. The password itself never leaves your device.
2. Each collection has its own data key. Items in that collection are encrypted under the collection's key, not directly under your password.
3. Collection keys are wrapped (encrypted) under your account keys. The server stores the wrapped keys but cannot unwrap them.
4. Sharing works by re-wrapping a collection key for another user's public key, so you can share one calendar without handing over everything.

This indirection is why changing your password is fast: only the wrapping layer changes, and the items themselves are not exposed as plaintext on the server. It is also why sharing a single collection does not expose the rest of your account.

Why not encrypt the metadata too?

A fair question: if the server can see item counts and timestamps, why not hide those as well? The answer is that a sync server fundamentally needs some structure to function. It has to know which revisions a device already has so it can send only the new ones. It has to know that an account has collections in order to list them. Hiding all of that would mean the server could not do its job, or would require shipping the entire dataset on every sync, which is impractical for a calendar you check several times a day.

The design choice Etebase makes is to encrypt everything that carries meaning and expose only the minimal structure required to sync efficiently. That is a deliberate trade-off, and being clear about it is more useful than claiming the server sees “nothing,” which is never quite true of any practical sync system.

FAQ

Does the SilentSuite server see my event titles?
No. Event titles, times, locations, attendees, and notes are encrypted on your device before upload. The server stores ciphertext.

Does the server see my calendar names?
No. Collection metadata, including the name, description, and color of a calendar or address book, is encrypted. A calendar named “Therapy” looks like an opaque blob to the server.

What can the server see, then?
Structural metadata: that collections exist, roughly how many items each holds, sync revision timestamps, and your account login identifier. It sees activity, not content.

What encryption does Etebase use?
XChaCha20-Poly1305 for symmetric encryption and Argon2 for deriving keys from your password, the same primitives provided by libsodium. SilentSuite is built on the Etebase protocol and uses these directly.

Is the encryption open source?
Yes. The SilentSuite server is AGPL-3.0 and the Etebase protocol is open, so the encryption can be inspected rather than taken on trust. SilentSuite has a hosted plan listed as “From €3/mo” and is self-hostable.

End-to-end encryption is a precise claim, and precision is the point. With SilentSuite, the contents of your calendars, contacts, and tasks are encrypted client-side and unreadable to the server, the host, and us. The server sees the minimal metadata it needs to sync, and nothing about what your data means.

Get started with SilentSuite, or read our threat model for the bigger picture of who this protects you against.