State and Threat-Adaptive Asymmetric Forward Secrecy

For contemporary end-to-end encrypted protocols, [forward secrecy] is essentially required to protect users and their communications over time. It limits the impact of key compromises through ephemeral keys. In asynchronous messaging systems, these ephemeral keys must be shared with conversation partners and remain available until decryption is needed1.

Implementing forward secrecy typically requires participants to track state. The widely-reviewed [Double Ratchet Algorithm] elegantly aligns multiple conversation partners' states, but necessarily relies on all of them maintaining this state information throughout their interaction.

But what if state itself was something one would want to avoid?

Threat Model Specialisation

Reach's design acknowledges a fundamental asymmetry in its users' threat profiles. Users initiating contact ("Reaching Users" or "Reaching Parties") typically face different security challenges than those receiving messages ("Reachable Peers").

For reaching users, localised threats predominate - abusive partners, employers, or local law enforcement gaining physical device access. Most of the time, these immediate physical risks outweigh the sophisticated state-level attacks that might target receiving organisations or collectives.

Communication patterns further exacerbates this asymmetry. Reaching users send and receive far fewer messages than reachable peers, making key reuse for messages sent to reachable peers a more significant security risk than the reverse scenario.

Many end-to-end encrypted systems that offer Forward Secrecy without requiring users to maintain device state typically store key material and state information on their servers. However, this approach allows servers to enumerate, identify, and distinguish between their users. Reach recognises that servers frequently operate in cloud environments where third-party access cannot be avoided, therefore, Reach intentionally avoids offloading state to servers.

An Approach with Trade-Offs

Reach's unusual threat model demands unconventional security trade-offs. The twin requirements of avoiding state tracking whilst preventing adversaries with server access from distinguishing between users and user types necessitates a private-information-retrieval based polling mechanism for message delivery. This contrasts with the push notification approach common in popular encrypted messaging platforms.

While this design choice limits Reach's deployment scale, it aligns perfectly with the intended use case: asynchronous communication by smaller groups that more closely resembles email rathern than instant messaging.

For Reachable Peers, the system delivers strong security guarantees. Both Forward and Backward Secrecy are provided through the distribution of new asymmetric encryption keys during each message polling cycle. This ensures that even if an adversary compromises the keys for an individual message, both previously obtained and future messages remain secure.

By contrast, the Reaching Party uses the same asymmetric encryption keys throughout a defined temporal window to receive replies, after which messages automatically expire. This approach represents a significant departure from systems employing protocols like the Double Ratchet Algorithm, but constitutes a carefully calculated compromise based on Reach's unique security priorities.

Asymmetric Security Properties by Design

In conclusion, Reach deliberately implements different security guarantees for its two user types, reflecting their distinct threat models, resulting in asymmetric Forward (and Backward) Secrecy properties:

Reachable Peers

  • Benefit from full Forward and Backward Secrecy.
  • Have unique encryption keys distributed for each polling cycle.
  • Maintain strong protection against key compromise, as each compromise affects only a single message.

Reaching Users

  • Prioritise minimising device state and server-side identifiers.

  • Benefit from partial Forward and Backward Secrecy by using the same keys for limited (overlapping) time windows.

  • Accept the calculated risk of using consistent keys during these windows.

  1. This may happen with significant delay. See also: Fallacies of distributed computing, point 2 [forward secrecy]: https://en.wikipedia.org/wiki/Forward_secrecy [Double Ratchet Algorithm]: https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm ↩