How Encrypted Messaging Actually Works in GatherSafe

"Encrypted" gets used loosely in app marketing, and it matters what it actually means for a security team discussing threat descriptions and medical information. Here's exactly what GatherSafe encrypts, who holds the keys, and — just as important — what encryption here does not protect against.

The short version

GatherSafe encrypts messages with AES-256-GCM, a well-established, authenticated symmetric encryption algorithm. Every group gets its own encryption key. Messages are stored in the database as ciphertext plus an initialization vector (IV) — never as plain text. That protects your team's conversations from anyone who gains unauthorized access to the database or intercepts traffic in transit.

How a message actually gets encrypted

Here's the real flow, not a simplified marketing version of it:

• The first time a group needs to send a message, the server generates a 32-byte AES key for that group and stores it server-side.
• Your device fetches that key over an authenticated, TLS-protected request — only members of the group can retrieve it — and caches it in the device's Keychain (iOS) or Keystore (Android), the same secure hardware-backed storage used for passwords and biometric credentials.
• When you send a message, your device encrypts the text locally with that key before it ever leaves your phone, and transmits only the ciphertext and IV.
• The server stores that ciphertext in Postgres. It never sees the plaintext of the message you typed — encryption and decryption both happen on-device.
• Recipients' devices fetch the same group key and decrypt locally.

Why keys rotate when someone leaves

When a member is removed from a group, the server generates a brand-new key for that group and distributes it to the remaining members on their next fetch. That member can no longer decrypt anything sent after their removal. Messages sent before removal remain readable to them if they cached the old key locally before losing access — key rotation prevents future access, it doesn't retroactively revoke a key already downloaded to a device. We document this plainly rather than imply a guarantee it doesn't make.

What "server-managed keys" means for your threat model

Because the server generates and holds each group's key (to distribute it to members and support features like message search and admin tooling), the server is in a position to decrypt message content if it needed to — whether that's a database breach, a compromised admin credential, or a legal subpoena compelling disclosure. That's different from an end-to-end encrypted system like Signal, where even the service provider mathematically cannot read message content. GatherSafe does not make that claim, because it wouldn't be true.

What protects your data, concretely:

• TLS 1.2+ on every connection to the server, protecting against network eavesdropping.
• AES-256-GCM ciphertext at rest in the database, protecting against someone who gets read access to the database without the keys.
• Strict per-organization and per-group authorization checked on every API call and socket event, so members of one church's security team cannot see another organization's data, and sub-group members cannot see other sub-groups.
• Biometric or PIN app lock and Keychain/Keystore-backed local storage, protecting a lost or stolen phone.

What it does not protect against:

• A compromise of GatherSafe's own database or infrastructure.
• A compromised organization admin account — admins can invite users and read group content, and there is currently no second authentication factor required for admin actions.
• Legal process. A subpoena or discovery request can compel GatherSafe to produce decrypted content, because the server has the technical ability to decrypt it.

We keep the full threat model — every scenario, what it protects and what it doesn't — documented and up to date, because a security team deserves a precise answer instead of a marketing one.