Technical note · 8 September 2026

How Buddie encrypts your data.

Most apps in this category can read everything you put into them. Buddie cannot, and this page is the mechanism rather than the adjective. It is written for the person who has to sign off on a vendor, so it includes the parts that are inconvenient for us.

The short version

Three keys, three channels.

Content is sealed on your device before it is sent. The server receives ciphertext and a key that has itself been wrapped, so there is no position from which we could read it — not under subpoena, not by an engineer with database access, not after a breach of our infrastructure.

Yours alone

The personal channel

Everything you save is sealed under a master key derived from your password. It exists on your devices and nowhere else. We cannot reset it for you, which is the direct cost of us being unable to read your data.

You and one other

The partner channel

Each account holds an X25519 keypair whose private half is wrapped by that master key. Two partners derive a shared key from their own private key and the other's public key. The shared key is computed independently on both devices and never transmitted.

Everyone with a seat

The team channel

A random team key is generated on one member's phone, then sealed separately for every other member against their public key. Each person unwraps their own copy. The key is never assembled on the server, so holding all the sealed copies gets an attacker nothing.

What the server holds

Everything we store, and why none of it reads.

Item contentnotes, links, transcripts

Ciphertext, plus a wrapped key

AES-GCM. The per-item key is itself encrypted under your master key, which the server has never seen. The row we store is meaningless without a device.

Photos and voice notesobject storage

Sealed files, stored as .enc

Each file gets its own key, sealed on the device before upload. Our storage bucket holds bytes we cannot open. The file is 28 bytes larger than the original, which is the encryption envelope.

Public keysone per account

Stored in the clear, deliberately

A public key is public by design. It is what lets an admin seal the team key for a new member. On its own it opens nothing.

Reminder timesthe one exception

Stored readable

A reminder has to fire when your phone is off, so the server needs to know when. It knows the moment, never what the reminder is about. We would rather name this than let you discover it.

The honest part

What encryption cannot do.

Revoking a seat stops future access. It does not reach backwards. Anything a person already downloaded stays on their device, because the content was decrypted there and we have no channel to reclaim it.

This is not a gap in our implementation. It is what end-to-end encryption means. Any vendor who tells you they can remotely wipe content a user has already read is describing a system that can reach into the user's data, which is the same capability that lets them read it. You cannot have both properties at once, and we chose the one that protects your clients.

Two more limits worth stating. If you forget your password, we cannot recover your content; a recovery code issued at signup is the only route back. And we hold no SOC 2 or ISO 27001 certification today, so what is written here is an architecture you can inspect rather than an audit you can file.

For your reviewer

If a vendor cannot tell you where the keys live, they are the answer.

Ask us anything about this Read the business case