What can go wrong with encryption in a mesh messaging app?

Mesh messaging has been studied in the open. Two papers at academic security conferences analysed Bridgefy, a messaging app and SDK that uses Bluetooth mesh networking. They describe the versions their authors examined, not any later release.

• 2021. In “Mesh Messaging in Large-scale Protests: Breaking Bridgefy” (CT-RSA 2021), Albrecht, Blasco, Jensen and Mareková report that the app, as analysed, permitted its users to be tracked, offered no authenticity and no effective confidentiality protections, and lacked resilience against adversarially crafted messages. Their abstract says an adversary could produce social graphs, read messages, impersonate anyone to anyone and shut down the network with a single maliciously crafted message.
• 2022. In “Breaking Bridgefy, again: Adopting libsignal is not enough” (USENIX Security 2022), Albrecht, Eikenberg and Paterson analysed the revised messenger and SDK after the developers adopted the Signal protocol. The abstract describes an attack on private messages through a time-of-check to time-of-use issue, and one that recovered broadcast messages without the network-wide shared key. It also reports that an attacker-in-the-middle attack, impersonation in the broadcast channel, a decompression-bomb denial of service in limited form, and privacy issues remained.

The second paper’s title is the general lesson: a sound cryptographic library does not secure an app on its own. What matters is how keys are authenticated, how messages are parsed, and what travels outside the encryption.

Encrypting to a key you have not verified means encrypting to whoever supplied it. In a mesh, keys usually arrive over the same radio an attacker can use, which makes attacker-in-the-middle substitution the first thing to rule out. The X3DH specification says that if parties do not authenticate each other’s keys, they receive no cryptographic guarantee about who they are talking to.

The fixes are well known: compare fingerprints or scan QR codes in person, use trust on first use with a clear warning when a key changes, or check credentials an issuer signed in advance. RFC 9750 recommends credentials that bind an identity to its key cryptographically over ones that do not. A related class of bug is the time-of-check to time-of-use gap, where one value is checked and a different one is used later; the 2022 abstract names such an issue as the route to its attack on private messages.

Encryption alone hides content but does not stop changes to it. Without an integrity check, an attacker can alter ciphertext, and a receiver that reacts differently to bad padding or bad formatting can leak the plaintext a little at a time. RFC 7457 describes this padding oracle family in TLS and notes that the Lucky Thirteen variant can be mitigated by authenticated encryption such as AES-GCM, or by encrypt-then-MAC.

Authenticated encryption (AEAD), defined as an interface in RFC 5116, encrypts and authenticates in one step. In a group, that proves only that the sender knows the group key, so protocols add signatures. MLS signs messages with each member’s credential key, and RFC 9420 makes receivers reject encrypted messages whose padding is not all zero bytes.

Compressing secret data together with data an attacker controls can leak the secret through the length of the result. RFC 7457 summarises the CRIME and BREACH attacks of this kind. Decompression is a risk in its own right: a small message can expand into far more data than a device can hold, which is the decompression bomb in the 2022 abstract. Any message parsed before it is authenticated is input from a stranger. Bound sizes, reject malformed input early, and authenticate before doing expensive work.

A valid message recorded and sent again is still valid unless something stops it. X3DH notes that an initial message which does not use a one-time prekey can be replayed and accepted. MLS uses KeyPackages only once, to avoid replay, and RFC 9750 says even a fully compromised Delivery Service should not be able to remove, reorder or replay messages without detection. Above the encryption, an app still needs message identifiers and idempotent handling, because mesh relays can deliver the same message more than once.

A key shared by every copy of an app protects nothing from other users of that app. Group messages need keys held only by the group, changed when members leave. MLS does this and adds forward secrecy and post-compromise security, described in using MLS for group messaging on mobile.

In a mesh, every relay is a device the sender does not control, so encryption must run end to end, not only hop by hop on each radio link. Even then, metadata leaks. RFC 9750 says MLS assumes the transport keeps metadata private from network observers, and that optional MLS padding reduces what message length reveals. On a local radio network, stable identifiers in advertisements, timing and message sizes can show who is near whom. Tracking users and building social graphs are among the 2021 paper’s findings. How end-to-end encryption works without a server covers the key exchange side.