Encryption

Last updated: February 27, 2026

At Brrro, privacy is designed into every messaging layer, not added as an afterthought.
This page explains exactly how encryption works across direct messages, group chats, stories, media, and calls, in both plain language and technical detail.

Security model in one minute

Brrro is built so message and media content are encrypted on the sender’s device and decrypted only on recipient devices.

What this means in practice:

• Brrro servers route encrypted data but are not designed to read plaintext message content.
• Encryption keys are generated and stored on device.
• Group messaging uses MLS (Message Layer Security) session management.
• Stories and media are encrypted before upload.
• Calls use encrypted WebRTC transport, with encrypted signaling in modern flows.

1. Identity and key lifecycle

Each account/device has cryptographic identity material created on device.

Core properties:

• Device keys are generated client-side.
• Private key material stays on device.
• Public key material is used for routing/session establishment.
• MLS key packages are uploaded and consumed for session setup and membership changes.
• Sealed-sender-style token flows are used to harden sender authenticity in relay paths.

2. MLS-based secure sessions (direct + group)

Brrro’s primary modern messaging/session architecture uses MLS via the native BrrroMLS bridge.

What MLS provides in Brrro:

• Group state managed through commits/welcomes.
• Per-device key package upload and consumption.
• Secure membership transitions (join/remove/update).
• Encrypted message payload delivery over relay transport.

Important behavior:

• If session state is temporarily out of sync, the app performs recovery steps (inbox pull, directory refresh, retry) instead of silently dropping data.
• Key-package lifecycle is actively managed on server and client.

3. File and attachment encryption

Attachments are encrypted before they leave device memory for upload.

Media/attachment crypto:

• Cipher: AES-256-GCM.
• Per-attachment random key generated client-side.
• Integrity hash (SHA-256) tracked for payload integrity workflows.
• Encrypted blob uploaded to media endpoint.
• Decryption key is shared through encrypted message/story payload paths.

Local storage behavior:

• Encrypted attachment storage is used on device.
• Decrypted cache is ephemeral and can be cleared.
• Device-local master key material is kept in Keychain-backed storage.

4. Stories encryption

Stories use a two-layer secure model:

• Story payload metadata is MLS-encrypted per intended recipient.
• Story media bytes are encrypted (AES-GCM) before upload.

Operationally:

• Author creates story payload and media on device.
• Media is encrypted and uploaded as ciphertext blob.
• Recipient-specific encrypted payloads are generated.
• Author-side encrypted payload path is retained for local archive/decrypt resilience.

This design avoids storing plaintext story media on backend media infrastructure.

5. Call and video-call encryption

Brrro calls have two relevant security layers:

Media transport security

• WebRTC peer connections are used.
• DTLS-SRTP is enabled for media transport encryption in transit.

Signaling security

• Call signals encapsulated in encrypted MLS message envelopes.
• This means offers/answers/candidates are not intended to be exposed as plaintext application payloads in normal encrypted paths.

6. Screenshot / screen-recording protections

Brrro includes anti-capture signaling and runtime protections, especially in sensitive contexts.

Implemented controls include:

• Screenshot/screen-record detection hooks.
• In-call warning propagation events.
• Runtime mitigation logic (including playback muting behavior during capture states in call flows).

No client-side anti-capture is perfect on all device states/OS behavior, but Brrro treats capture events as first-class privacy signals.

7. Push notifications and metadata boundaries

Even with E2EE, some metadata is necessary for delivery.

Data that may be processed for routing:

• Sender/recipient account IDs and device IDs.
• Message type and delivery timestamps.
• Limited notification metadata needed for UX (for example short preview text when enabled by flow).
• Group/thread identifiers needed to route to the right conversation.

Data not intended to be readable by server in normal encrypted paths:

• Plaintext message body.
• Plaintext story payload.
• Plaintext encrypted attachment media.

8. What Brrro can and cannot see

Brrro infrastructure is designed to process encrypted traffic, not message meaning.

Brrro can generally see:

• Transport metadata required for delivery and abuse prevention.
• Account/device identifiers involved in routing.
• Operational telemetry and error surfaces.

Brrro cannot generally see:

• Plaintext of E2EE messages.
• Plaintext media encrypted client-side.
• Plaintext MLS-protected payload content.

9. Reliability and key-change handling

Real-world encrypted systems fail if key lifecycle is ignored. Brrro includes:

• Key-package refresh and retry routines.
• Recovery flows for pending MLS messages.
• Session resync behavior after offline periods or device state drift.
• Defensive handling when key material is missing/outdated.

The goal is simple: users should get delivery, not cryptographic error screens.

10. Security limits

Brrro security does not protect against:

• A compromised endpoint device.
• Malicious OS-level instrumentation on rooted/jailbroken devices.
• User-approved data exfiltration outside encrypted channels.
• Metadata-level analysis by network/provider infrastructure.

Brrro security does meaningfully protect against:

• Server-side plaintext content exposure.
• Passive interception of encrypted payload content.
• Tampering of encrypted payloads without detection.

11. Summary for technical readers

Cryptographic components currently used in Brrro include:

• HKDF-SHA256.
• AES-256-GCM (attachments/media encryption).
• MLS session management and group state cryptography via native MLS engine.
• WebRTC DTLS-SRTP media transport encryption for calls.