Briar's Technical Anatomy: Tor, Bluetooth, and P2P Encrypted Messaging

Briar is a project that questions nearly every assumption of messaging architecture. No central server. No cloud backup. No email address or phone number required to create an account. All data is stored only on the device; messages are delivered directly between devices. When internet access is unavailable, it operates over Wi-Fi or Bluetooth; when internet is available, it uses the Tor network. This architecture targets journalists, activists, and those who need to communicate in surveilled environments.

Bramble: Briar's Transport Infrastructure

Briar's transport layer is called Bramble. Bramble unifies multiple physical transmission media (Tor, Wi-Fi, Bluetooth) behind a single abstract transport interface. Upper layers do not need to know which physical medium a message is traveling through.

Bramble offers three transport plugins:

TorPlugin: The primary transport used when internet connectivity is available. Briar uses Tor's hidden service (onion service) infrastructure to establish a direct connection with the recipient. Each Briar user has a .onion address that conceals their real IP address and makes network surveillance difficult.

WiFiPlugin: A direct TCP/IP connection between devices on the same local area network (LAN). mDNS (Multicast DNS) and Wi-Fi Direct are used for local network discovery. No internet required.

BluetoothPlugin: Serial connection over Bluetooth RFCOMM (Radio Frequency Communication). Uses Bluetooth Classic, which offers higher data rates than BLE but greater battery consumption. Two devices can communicate without pairing.

Tor Integration: Onion Service Architecture

The way Briar communicates over the internet is fundamentally different from WhatsApp or Telegram. Rather than connecting to a central server, Briar creates a persistent Tor onion service for each user.

The process in this architecture works as follows:

1. When Briar is first launched, the Tor service starts and a .onion address is generated. This address is the user's permanent network identity.
2. Two users perform a contact exchange to add each other's contacts. This exchange takes place in person (via QR code) or over a secure channel.
3. When a message is sent, Briar connects to the recipient's .onion address via a Tor circuit. This conceals routing information: neither the sender's nor the recipient's IP address is visible to the other party or to the network.

Tor circuit establishment introduces additional latency: initial connection can take 5-30 seconds. This represents meaningful latency for real-time messaging, but since Briar is a privacy-focused tool, this trade-off is a deliberate design choice.

Synchronization Protocol: Graph-Based Message Store

Briar's most distinctive engineering contribution is how it solves message synchronization without a central server. It uses a Directed Acyclic Graph (DAG)-based message store.

Each message contains one or more references to preceding messages. This structure cryptographically secures message ordering and provides consistent merging in the event of conflicts. When two devices connect, a graph comparison is performed to identify missing messages; only missing nodes are transferred.

This model allows two users who have been offline for several hours to synchronize their conversations consistently when they reconnect.

Encryption Architecture

Briar uses a protocol called BambooContact for encryption. The core components are:

Identity Keys: Each user is identified by an Ed25519 key pair generated on the device and stored on the device. This key is never uploaded to the cloud or registered with a server.

Session Key Exchange: During contact exchange, two parties generate a shared secret using Curve25519 Diffie-Hellman exchange. This secret is used to derive encryption keys for all subsequent communications.

Message Encryption: Each message is encrypted with AES-256-GCM. Message integrity and authentication are integrated into the encryption algorithm (GCM's authenticated encryption property).

Forward Secrecy: New keys are derived for each connection session. Compromise of a session key does not expose previous sessions.

Briar Mailbox: The Asynchronous Delivery Problem

The most critical weakness of Briar's P2P architecture is that it requires both parties to be online simultaneously. If the recipient's application is closed, the message cannot be delivered.

Briar Mailbox was developed to solve this problem. A Mailbox is a background service run by a trusted user on their own Android device. Messages are stored end-to-end encrypted at this intermediate node until the recipient comes online.

An important note: the Mailbox operator cannot read the messages. The encryption key exists only on the sender's and recipient's devices; the Mailbox only stores and forwards encrypted bytes.

Local Network and Bluetooth Usage

In offline mode, Briar automatically switches to local transport options:

Wi-Fi Mode: Devices connected to the same Wi-Fi network discover each other via mDNS. A direct TCP/IP connection is established; messages are transmitted without Tor, but still encrypted. This mode provides high speed in campus or local network scenarios.

Bluetooth Mode: Serial connection over Bluetooth RFCOMM. Slower than Wi-Fi, but requires no network infrastructure. Two devices can communicate directly without any access point.

In both modes, the encryption is identical: even as the transport changes, application-layer encryption remains active.

Performance Characteristics

Briar is optimized for strong privacy, not high performance. This means concrete limitations for real-time use:

• Initial Tor connection: 5-30 seconds
• Message delivery latency (Tor): 1-10 seconds, depending on circuit quality
• Local Wi-Fi latency: 50-500 ms
• Bluetooth latency: 100 ms to several seconds (depending on connection quality)
• File transfer: Better than BLE in Bluetooth mode, but large files remain slow

Security Model: What It Protects Against, What It Does Not

Briar's security model is designed for specific threat profiles:

What it protects against: Network-level reading of communication content; identification of who communicates with whom through metadata analysis (Tor mode); accessing messages without physical access to the device; compromise of a central server (there is none).

What it does not protect against: Physical device access — if the device is seized, messages can be read (partially mitigated by database encryption). Traffic analysis attacks — Tor's known limitations apply. Application-level monitoring while Briar is running.

Conclusion

Briar is one of the applications that most radically implements the principle of zero dependency on centralized infrastructure. Tor integration, multi-transport support, DAG-based synchronization, and device-stored identity keys constitute a technically coherent, privacy-first architecture. This architecture is strong for high-privacy requirements, while presenting serious limitations in terms of ease of use and real-time communication speed.