mirror of https://github.com/status-im/specs.git
91 lines
5.3 KiB
Markdown
91 lines
5.3 KiB
Markdown
---
|
|
sip: x4
|
|
title: Initial Status Protocol Overview
|
|
status: Draft
|
|
type: Standard
|
|
author: Adam Babik <adam@status.im>, Oskar Thorén <oskar@status.im>, Dean Eigenmann <dean@status.im>
|
|
created: 2019-04-18
|
|
updated: 2019-08-26
|
|
---
|
|
|
|
# Abstract
|
|
|
|
In this document, we specify a secure and decentralized messaging protocol, onwards called Status Protocol, that is capable of running on the Ethereum network.
|
|
|
|
<!--
|
|
# Protocol overview
|
|
|
|
TODO:
|
|
* why p2p?
|
|
* why on Ethereum stack?
|
|
* designed for mobile from the beginning
|
|
-->
|
|
|
|
# Protocol Layers
|
|
|
|
The Status Protocol stack consists of multiple protocols. In this document, we give a brief overview of each layer and what they provide. We also note any specific considerations when it comes to using these components together.
|
|
|
|
| Layer | Purpose | Technology |
|
|
|-------------------|---------------------------------|------------------------------|
|
|
| Data | End user functionality | 1:1, group chat, public chat |
|
|
| Security | Confidentiality, PFS | Double Ratchet |
|
|
| Privacy | Metadata protection | Whisper |
|
|
| P2P | Overlay routing, NAT traversal | devp2p |
|
|
|
|
> Note that the Status Protocol was documented after the fact, which might lead to some inconsistencies or questionable design choices.
|
|
|
|
# Data Sync Clients
|
|
|
|
Data Sync Clients specify a format of payloads exchanged between clients communicating using the Status Protocol. The robust and well-defined format is required in order to provide some security guarantees, for example, clients should not display messages that do not conform to the format, and allow the clients to upgrade the protocol safely in the future.
|
|
|
|
The well-defined format also makes it possible to support multiple types of conversations as well as multiple types of content.
|
|
|
|
Please refer to [Initial Message Payload Specification](x8.md) for more details.
|
|
|
|
# Data Sync Layer
|
|
|
|
[MVDS](https://specs.vac.dev/mvds.html) is used for 1:1 and group chats, however it is currently not in use for public chats.
|
|
|
|
# Conversational Security Layer
|
|
|
|
Conversational Security Layer provides various cryptographic properties:
|
|
|
|
1. **Confidentiality** - Ensure only intended recipients are able to read a message.
|
|
2. **Integrity** - No honest party will accept a message modified in the transit.
|
|
3. **Authentication** - Each participant in the conversation receives a proof of possession of a known long-term secret from all other participants. In addition, each participant is able to verify that a message was sent from the claimed source.
|
|
|
|
This assumes trust has already been established, see [Initial Trust Establishment Specification](x5.md).
|
|
4. **Forward secrecy** - Also known as perfect forward secrecy (PFS), gives assurance that session keys will not be compromised even if the private key is compromised. Also, compromising one session key will not result in compromising other sessions.
|
|
|
|
Please refer to [Initial Conversational Security Specification](x6.md) for more details.
|
|
|
|
# Transport privacy layer
|
|
|
|
The purpose of the transport privacy layer is to hide metadata (provide darkness) that are always sent when communicating over the internet. In some cases, leaked metadata might be as dangerous as leaking the actual payload so it's important to reduce that.
|
|
|
|
The Status Protocol uses [Whisper in version 6](https://github.com/ethereum/wiki/wiki/Whisper) as a privacy protection protocol. Whisper routes messages by broadcasting them to all connected peers so that identifying of the recipient is almost impossible (the sender is not equally protected, though). [Read more](https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness) about how Whisper achieves darkness.
|
|
|
|
Note: there is one more cross-layer dependency in the Status Protocol between the privacy and data layers. Whisper uses topics to reduce traffic and preliminarily filter out messages. However, selecting a topic depends on the type of the message that is a topic for 1-1 chat will be different from a topic for a public chat.
|
|
|
|
Please refer to [Initial Transport Privacy through Whisper Specification](x7.md) for more details.
|
|
|
|
# P2P layer
|
|
|
|
P2P layer allows various clients to securely communicate with each other through the internet in a decentralized fashion, eventually forming a peer-to-peer network. Due to our close relationship to Ethereum and the fact that Whisper is built on top of [devp2p](https://github.com/ethereum/devp2p), we use [devp2p](https://github.com/ethereum/devp2p) as a P2P layer.
|
|
|
|
A client in order to rely a message needs to first find other clients (this process is called node discovery and is out of scope of this specification) within the peer-to-peer network. Then, the message needs to be properly routed handling obstacles like NAT traversal. All these things are handled by devp2p.
|
|
|
|
<!--
|
|
# Censorship resistance
|
|
|
|
TODO
|
|
-->
|
|
|
|
# Dependencies between layers
|
|
|
|
As it was mentioned above, there are cases when two layers depend on one another:
|
|
* encrypting messages is done by the privacy layer instead of security layer
|
|
* the privacy layer needs to know some details of the payload to properly route it.
|
|
|
|
In the next version of the protocol, we will try to remove these dependencies so that all layers are orthogonal and if necessary there is a clean interface between one and another.
|