-
Notifications
You must be signed in to change notification settings - Fork 5
Home
Welcome to the Wiki of Hopr π
Table of contents Wiki Key features Technical Description Usage Background Messaging should be done in a secure way. It seems to be clear what secure means but when digging deeper in the details, the definition of secure communication becomes more complex:
secure communications should prevent unauthorized parties from learning the content of the message. This security goal is known as confidentiality and is achieved by reasonable encryption schemes like AES. the sender of the message also wants to make sure that manipulations to the message are observable by the designated receiver. That property is known as integrity and can be achieved by using a suitable scheme that generates message authentication codes like HMAC. The combination of both schemes yields a construction that allows a sender to hide the content of the message and make the integrity of the message verifiable. However, this construction does not hide that sender and receiver have exchanged messages. It also leaks an upper bound that shows how much communication took place. A possible adversary might therefore also distinguish short conversations from longer ones. If the adversary also were able to observe actions that follow the reception of messages, the adversary might be able reason about the content of the observed encrypted data - without breaking the encryption scheme. This shows that in some cases confidentiality and integrity is not enough and it is also mandatory to protect metadata.
To hide who is communicating with whom, sender and receiver need other parties that helps them hiding that kind of information. More precisely, sender and receiver will always rely on services of other parties. There might be parties that deliver this service for free in order to support their ideological beliefs. For free means in that context that these parties pay the incurred costs. These costs include not only the price to buy the requirred hardware but also recurring costs like electricity or bandwidth. In addition, one might also consider legal costs in order to deal with abuse complaints.
If there is no incentive to run a service that provides anonymity, people that use this network need to rely on altruistic parties that offer such a service for the greater good. It seems therefore reasonable to compensate the parties that provide anonymity as a service. This becomes especially important if one relies on such a network or wants to run an application on top of such a network at scale.
Key features Metadata protection Comprises message layer and payment layer Privacy-preserving payments for relay operators to incentivize them Automatic dispute resolution for payments Decentralized message delivery & decentralized directory service through WebRTC No usage of inefficient cryptographic building blocks like homomorphic encryption or zero-knowledge proofs Works with any coin or token as a medium of exchange Agnostic to the choice of token / coin / blockchain*
- The blockchain needs to support basic smart contracts.
State of the art TOR Whisper Orchid HOPR Asymptotic message overhead O(# of hops) O((# of participants) ^ 2 * TTL) O(# of hops) O(# of hops) Decentral partially* β β β Sender anonymity β ** β ?? β Receiver anonymity β ** β ?? β Incentivations β β β β Privacy-preserving Incentivations N/A N/A β*** β Note: the message overhead is given in Big-O Notation to express the asymptotic amount of messages that are necessary to send a message through the network.
- Not fully decentral due to central directory service. ** If entry node and exit node don't collude. *** Probably in a future version according to the whitepaper.
For further details, have a look at a more detailed comparison.
Technical Description The construction consists of two layers: one for message delivery and one for payments. Messages are embedded within SPHINX packet format that provably hides the relation between sender and receiver. The payment layer uses off-chain payments via payment channels and node operators need to stake assets to process transactions.
The protocol consists of multiple layers:
- The network layer establishes a peer-to-peer connection between the nodes. To achieve that, the implementation uses libp2p in combination with WebRTC to bypass NATs. This allows each node to become a relay node and earn money.
- The messaging layer hides the connection between sender and receiver of a message. Therefore it uses slightly modified version of the SPHINX packet format by G. Danezis and I. Goldberg.
- The payment layer ensures that each node has to pay for the relaying service of other nodes. It also provides security against nodes that try to grab more money as intended by the receiver.