Adaptive Privacy

Published in

HOPR

3 min readMar 20, 2023

With the release of RPCh, the first commercial service developed on HOPR, it is a great time to discuss the concept of adaptive privacy. But first, we’ll need to go over a constraint inherent to all anonymous communication (AC) protocols — the anonymity trilemma.

What is the anonymity trilemma?

The anonymity trilemma states that any AC protocol can only choose two: low bandwidth overhead, low latency, or strong anonymity.

It is widely accepted that low bandwidth overhead and low latency AC protocols such as Tor can only provide a weak form of anonymity. Tor is demonstrably vulnerable to various traffic correlation attacks. Here we define strong privacy under the threat model, where we must obscure the source and destination of traffic movement from a powerful global passive adversary that can additionally passively compromise some of the nodes on the network.

In most AC-related literature, a protocol that can defend against this threat model is considered to be extremely private but usually comes with one of two tradeoffs:

High latency as is the case with threshold mixnets that rely on communication delays.
High bandwidth overhead as seen with approaches such as the “Dining cryptographers” network or its extensions, where they rely on sufficient background noise to generate anonymity.

HOPR employs both these concepts, but as a comprehensive solution, it aims to provide the tools and customization necessary for services developed on the network to choose their own ideal tradeoffs.

HOPR’s Approach to the Anonymity Trilemma

HOPR’s long-term architecture employs the following privacy features that all contribute to the latency/bandwidth tradeoffs:

Packet Mixing
Background Noise (Cover Traffic)
Multi-hop Relays
Indistinguishable Data Packets

Indistinguishable Data Packets

All packets relayed of HOPR are standardized into indistinguishable Sphinx packets, meaning each packet’s payload and header must be identical in size across all packets.

Each header contains routing information for its relay, including information for anonymous return pathing. And any unused space is padded to keep each header uniform. This is all unavoidable bandwidth overhead necessary for HOPR to bring you the privacy guarantees it boasts.

Background Noise

Cover traffic will also use up bandwidth for dummy packages that are similarly indistinguishable from real traffic. These standardize the network’s noise to sufficiently obscure traffic movement but also reduce the bandwidth for real traffic.

Packet Mixing

Packet mixing trades latency for privacy, using delayed mixing cycles to re-route and mix data packets such that their destination is obscured from an observer.

Multi-hop relays

Multi-hop relays trade both latency and bandwidth for privacy, adding extra intermediaries with a non-zero latency to process their part of the relay. Additionally, they simply use more nodes per relay.

Note that the number of hops you choose does not increase the bandwidth through increased routing information within the packet header, as this is padded to a standardized size regardless of the relay length.

Adaptive Privacy & HOPR

Although using all these features at their maximal privacy offering is amazing, many of these privacy guarantees are inherent to the network. So you can always choose your ideal tradeoffs without worrying about your application’s privacy ever falling below the “strong privacy” threshold.

On the HOPR roadmap are features that allow users to customize: