News · Security at Blackbear

What We Can't Read

Blackbear is local-first. Every feature works on your device, and by default your data lives only there. No account required, no server in the loop.

When you do create an account and turn on cloud sync, our servers start carrying your data between your devices and your people. This series explains what that means for your privacy. Part 1 covers encryption: what leaves your device, and why we cannot read it. Part 2 is an honest ledger of the metadata our servers do hold. Part 3 covers sharing and collaboration.

Everything below is a description of shipped code, not intentions. Where we name an algorithm or a number, it is the one running in production today.

Encryption happens on your device

Every change you sync is encrypted before it touches the network. Notes, documents, tasks, events, journal entries, spreadsheets, canvases, audio, version history. Each one is sealed with XChaCha20-Poly1305, an authenticated cipher, using a key that never leaves your device unprotected. Our servers receive ciphertext and store ciphertext.

Images and audio files get the same treatment: encrypted on your device, uploaded as opaque blobs.

The code that does all of this is a single Rust implementation built on the RustCrypto ecosystem, compiled to WebAssembly. The app and the Blackbear CLI share it, byte for byte, and we test it against cross-language fixtures so no second implementation can quietly drift.

What this protects, and what it doesn't

Encryption is a specific tool, not a force field. Before the details, the boundaries.

The key hierarchy

Your passphrase never leaves your device. Everything grows from it:

• Your passphrase runs through Argon2id, a memory-hard key derivation function, tuned to 64 MiB of memory, three passes, and four lanes. Out comes your Account Key.
• Your Account Key wraps your Vault Key: a random 256-bit key generated on your device. The Vault Key is what actually encrypts your data.
• Our servers store the wrapped Vault Key, the salt, and the tuning parameters. The wrapped key is itself ciphertext. Without your passphrase, it is noise.

Why the indirection? It lets you change your passphrase without re-encrypting your entire life, and it lets recovery exist without weakening the front door.

A caution that belongs in print: Argon2id makes guessing expensive; it cannot make a weak passphrase strong. The wrapped Vault Key is exactly as strong as the passphrase that wraps it. Choose a long one.

Recovery is twelve words

When you set up sync, Blackbear gives you a recovery phrase: twelve words (BIP39) encoding 128 bits of entropy. They derive an independent key that wraps your Vault Key a second time.

Lose your passphrase? The twelve words get you back in. Lose both? Your synced data is gone. We cannot reset it, and no support ticket can talk us into it, because there is nothing on our side to reset. That is not a gap in our support. It is the design holding.

Adding a device

On a new device, you enter your passphrase. It derives your Account Key locally and unwraps the Vault Key from the wrapped copy our server holds. The server never sees the passphrase, and never sees the result.

An existing unlocked device can also hand the key over directly. It seals the Vault Key to the new device's X25519 public key and parks it in a transfer slot that self-destructs after five minutes, used or not. One honest boundary here: your existing device learns the new device's public key through your signed-in account, so this assisted path trusts our server to relay the right key for the device you chose. The passphrase path carries no such trust.

Because this vocabulary is exactly what a phisher would borrow, a rule worth stating in print: we will never ask for your passphrase or recovery words, and we will never ask you to approve a device transfer. Those prompts belong only inside an app you opened yourself. Anyone else asking is an attack.

Messages

Messaging uses its own keys, separate from sync. Each account has an X25519 messaging identity, and every message derives a unique key from a fresh per-message salt via HKDF-SHA256. Messages travel as sealed envelopes. The server relays them; it cannot open them. Part 2 covers what the outside of the envelope reveals.

One design note, stated plainly: unique keys per message are not the rotating-ratchet design some messengers use. If a device's long-term messaging key were ever compromised, messages sealed to it would be at risk. Per-message keys limit blast radius; they are not forward secrecy, and we would rather you know the difference.

History without content fingerprints

Version history syncs as encrypted snapshots, addressed by IDs scoped to your vault. If you and a stranger save an identical file, the server sees two unrelated IDs: identical contents cannot be matched across accounts. Size and timing remain visible, like all sync traffic. That is metadata, and Part 2 owns the subject.

Proving without revealing

Destructive account operations require a vault proof: a signature from an Ed25519 key derived from your Vault Key. You prove you hold the vault without the vault ever traveling. And when keys have done their work in memory, they are zeroed.

None of this is exotic. XChaCha20-Poly1305, Argon2id, X25519, Ed25519, HKDF-SHA256: standard, boring, heavily reviewed primitives. The interesting part is the discipline of applying them everywhere, and of saying out loud what they do not cover. That discipline is what the rest of this series is about.