PrivateFamily / Encryption explained

Encryption explained

Your photos are encrypted before they ever leave your phone

PrivateFamily is the end-to-end encrypted family photo album: here, step by step, is how we encrypt your photos before they're sent, what the server actually sees, and what's still left to encrypt. No overselling, no unnecessary jargon.

Step by step

The journey of a photo, from your phone to your family

Here's precisely what happens, technically, between the moment you tap "send" and the moment your mother opens the photo on her phone.

On your phone, before sending

As soon as you pick a photo, the app splits it into 1 MiB blocks and encrypts each one with your family's secret key — a key generated on that device, never anywhere else. What heads to the server is no longer a photo at all: it's a string of encrypted bytes.

On the server, on arrival

The server receives these encrypted bytes, stores them as they are, and will serve them as they are later on. It isn't sent the family key itself and generates no previews. A known limit does exist on invitations (see "Known limit" below).

On a relative's phone, on opening

When a family member opens the album, their phone downloads those same encrypted bytes and decrypts them locally, with its own copy of the family key. Decryption happens on the member's own device, never on the server.

Two ways to understand it

Simply, then in detail

Two ways to read this, depending on what reassures you most: a simple picture, or the exact cryptographic mechanisms we use.

Explained simply

Picture every photo leaving your phone already locked inside a sealed box. The key to that box is shared among the members of your family — a key made by a phone, never typed on a keyboard, never sent by email.

The server stacks sealed boxes on a shelf: it counts them, moves them around, hands them to the right person. When you invite someone close to you, your phone prepares a copy of the key, placed in an envelope sealed by the invitation code, which they open on their own phone. Known limit: during the invitation, the server keeps that code and the envelope (see below).

For the technically minded

Authenticated encryption with XChaCha20-Poly1305-IETF, via the react-native-libsodium library. The family key ("FDK") is 256 bits (32 bytes), generated at random on the device with randombytes_buf — never derived from a password.

  • 24-byte nonce: a 16-byte random prefix unique to each file, followed by an 8-byte big-endian block counter.
  • 1 MiB blocks (1024 × 1024 bytes), each encrypted independently with its own 16-byte Poly1305 authentication tag — which will one day make it possible to serve video clips by byte range, unlike one continuous encrypted stream.
  • Tamper-resistant: altering, truncating, or reordering a block, or substituting in a block from another file, reliably makes decryption fail — behavior covered by automated tests.
  • Key stored in hardware-backed secure storage: iOS Keychain / Android Keystore, via expo-secure-store — never in the app's regular storage, never transmitted over the network.
  • 12-word recovery phrase, drawn from the standard BIP-39 wordlist (2048 words) by a cryptographically random generator — about 132 bits of entropy. Shown once, when the family is created. The server stores only a SHA-256 hash of it, never the phrase itself; 5 wrong attempts lock recovery for one hour.
  • Argon2id derivation (crypto_pwhash, libsodium's INTERACTIVE preset) to recover the family key from the recovery phrase.
  • Inviting a new member: the inviting device, already unlocked, wraps a copy of the family key under a secret derived from the invitation code, and that sealed envelope travels through the server, which keeps the invitation code and the envelope (see "Known limit" below). The device joining the family downloads it and unwraps it locally with the code you entered. The code itself is 8 characters, limited-use, and expires after 30 days at most.
  • Thumbnails generated on the phone, never on the server, and encrypted the same way before upload.

In full transparency

What the server actually sees

Encryption protects the content of your photos and videos. It doesn't make the server blind to everything: here, plainly, is the exact line between what's encrypted today and what isn't yet.

Encrypted
Photos and videos

Encrypted end to end: the server stores and serves the content in encrypted form. Thumbnails are generated on the phone before encryption, and the dimensions the server knows are whatever the app itself declares to it.

Plaintext
What the server sees anyway

Metadata, never the content: the exact date and time each photo was taken (captured_at), the size and SHA-256 hash of the encrypted file, the image dimensions, and who sent, viewed, reacted to, or commented on it — via an internal account ID.

Encrypted
Captions, comments, child profiles, family names

Captions, comments, children's first names and birthdates, growth and milestone notes, family and member names, reaction emojis: end-to-end encrypted, with the same key as your photos.

Two honest nuances: numeric growth values (height, weight) stay in plaintext — only their date and notes are encrypted. Your account name, used to sign you back in on a new device, stays separate and unencrypted; it's the name shown to other members within each family that is.

Known limit: when an invitation is created, the server keeps the invitation code and the key envelope. We therefore cannot, today, promise that the server is unable to read the photos of a family that has created an invitation. A fix is in progress.

Another honest limitation: video playback currently downloads and decrypts the entire video before playing it. There's no real-time streaming decryption yet.

Frequently asked questions

What people ask us about encryption

Why does the server still see the photo's date?

The exact capture date (captured_at) is used to automatically sort your photos into the timeline, by month and year — sorting that currently happens server-side, which requires the server to know that date in plaintext. It's metadata about the photo, never its content: it doesn't show anyone what's actually in the picture.

What happens if I lose my phone?

Another admin or co-admin in your family can restore your access within seconds. If you're the only admin, the 12-word recovery phrase you received when the family was created lets you recover everything on a new device.

Does encryption slow down sending photos?

No, there's no perceptible difference. Encryption happens on your phone, at the same moment the app is already compressing the photo before sending it — a step that happened anyway.

Why not just use a family password?

Because a password chosen and remembered by humans is almost always weaker than a 256-bit key generated at random by a device. That key never even needs to be typed day to day: only the recovery phrase exists, as a personal safety net for each admin, meant to be used only if a device is lost.

Are comments and children's names encrypted?

Yes, since August 31, 2026: captions, comments, children's first names and birthdates, growth and milestone notes, family and member names, and reactions are end-to-end encrypted with the same key as your photos. Staying in plaintext, for technical reasons: numeric growth values (height, weight), your account name (used to sign you back in on a new device) and the metadata described above (exact date, file size, who sent it).

Ready to try it?

The safest encryption is the one you never have to manage.

Free: 10 photos per month. Two minutes to set up your family.