status-im
/
specs
mirror of https://github.com/status-im/specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #35 from status-im/simplify-specs 

Simplify specs
This commit is contained in:
Oskar Thorén 2019-08-27 14:09:07 +02:00 committed by GitHub
parent 4c42d1e886 41652402f4
commit cfa3212a96
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 83 additions and 355 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
x4.md
View File

@ -3,21 +3,23 @@ sip: x4
title: Initial Status Protocol Overview
status: Draft
type: Standard
author: Adam Babik <adam@status.im>, Oskar Thorén <oskar@status.im>
author: Adam Babik <adam@status.im>, Oskar Thorén <oskar@status.im>, Dean Eigenmann <dean@status.im>
created: 2019-04-18
updated:
updated: 2019-08-26
---
# Abstract
Ethereum empowers users and developers to interact with totally new kind of applications called Dapps (Decentralized applications). These application allows to interact with the blockchain on a completely new level which is not only about exchanging values but also executing arbitrary logic. This logic can form very sophisticated programs like DAOs (Decentralized autonomous organizations). The missing part here is how users of Dapps can communicate securely and in a decentralized way with each other. Communication is an essential part of any activity. In this document, we specify a secure and decentralized messaging protocol, onwards called Status Protocol, that is capable of running on the Ethereum network.
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
@ -32,33 +34,28 @@ The Status Protocol stack consists of multiple protocols. In this document, we g
> Note that the Status Protocol was documented after the fact, which might lead to some inconsistencies or questionable design choices.
# Data layer
# Data Sync Clients
Data layer specifies 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, client should not display messages that do not conform to the format, and allow the clients to upgrade the protocol safely in the future.
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 cryptographical properties to the Status Protocol:
* confidentiality
* integrity
* authentication
* forward secrecy.
Conversational Security Layer provides various cryptographic properties:
Confidetiality makes sure that only intended recipients are able to read a message.
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.
Integrity means that no honest party will accept a message modified in the transit.
Authentication means that 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. Initial trust establishment is detailed in [Initial Trust Establishment Specification](x5.md).
Forward secrecy, known also as perfect forwardsecrecy (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.
Note: The Status Procol can work with PFS enabled and disabled. In the case of disabled PFS, the encryption is moved to the Privacy Layer and handled by Whisper. Whisper does **not** provide forward secrecy. This is a flaw of the original design which mixes security and private layer responsibilities. With PFS enabled, a message is encrypted twice.
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.
@ -74,13 +71,15 @@ Please refer to [Initial Transport Privacy through Whisper Specification](x7.md)
# P2P layer
P2P layer allows various clients to securely communicate with each other through the internet in a decetralized fashion, envetually 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.
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

62
x5.md
View File

@ -21,33 +21,37 @@ TODO: Something briefly on adversary model, i.e. https://code.briarproject.org/b
TODO: Elaborate on section of requirements below
Security properties
Network MitM Prevented
Operator MitM Prevented
Operator MitM Detected
Operator Accountability
Key Revocation Possible
Privacy Preserving
Usability
- Network MitM Prevented
- Operator MitM Prevented
- Operator MitM Detected
- Operator Accountability
- Key Revocation Possible
- Privacy Preserving
- Usability
<br />
Automatic Key Initialization
Low Key Maintenance
Easy Key Discovery
Easy Key Recovery
In-Band
No Shared Secrets
Alert-less Key Renewal
Immediate Enrollment
Inattentive User Resistant
Adoptability
- Automatic Key Initialization
- Low Key Maintenance
- Easy Key Discovery
- Easy Key Recovery
- In-Band
- No Shared Secrets
- Alert-less Key Renewal
- Immediate Enrollment
- Inattentive User Resistant
- Adoptability
<br />
Multiple Key Support
No Service Provider
No Auditing Required
No Name Squatting
Asynchronous
Scalable
- Multiple Key Support
- No Service Provider
- No Auditing Required
- No Name Squatting
- Asynchronous
- Scalable
NOTE: Several of these we don't do, and e.g. ENS/mutlikey stuff can be noted as future enhancement
NOTE: Several of these we don't do, and e.g. ENS/multikey stuff can be noted as future enhancement
## Trust establishment
@ -135,7 +139,7 @@ comments:
> Key maintenance encompasses recurring effort users have to invest into maintaining keys. Some systems require that users sign other keys or renew expired keys. Usable systems require no key maintenance tasks
- no key maintenance is required, only safekeeping of the backup seed phrase.
- In the future, functionality like universal logins would be useful to extend the options of user-facing key maintanence and device risk/revocation.
- In the future, functionality like universal logins would be useful to extend the options of user-facing key maintenance and device risk/revocation.
#### Easy Key Discovery (YES)
> When new contacts are added, no additional effort is needed to retrieve key material.
@ -146,7 +150,7 @@ comments:
#### Easy Key Recovery (YES)
> When users lose long-term key material, it is easy to revoke old keys and initialize new keys (e.g., simply reinstalling the app or regenerating keys is sufficient).
- Key recovery is re-initializing your account with your backed up recovery phrase, which rederives all needed keys
- Key recovery is re-initializing your account with your backed up recovery phrase, which re-derives all needed keys
#### In-band (YES)
> No out-of-band channels are needed that require users to invest additional effort to establish.
@ -162,7 +166,7 @@ comments:
> If other participants renew their long-term keys, a user can proceed without errors or warnings.
- There is no key renewal for base trust establishment, a user is a public-key
- In the future, Universal logins will help with this maintanence and functionality
- In the future, Universal logins will help with this maintenance and functionality
#### Immediate Enrollment (YES)
> When keys are (re-)initialized, other participants are able to verify and use them immediately
@ -202,8 +206,8 @@ comments:
> Users can choose their names and can be prevented from reserving a large number of popular names
- In general, yes.
- Public keys have a big space. For three-random words it is possible to generate arbitrary combinations with decent computational resources, but this doesn' amonut to "reserving" it.
- For ENS, no. But for each name, a stake of 10 SNT is required, as well as the creation of a new identity (unless they interact directly with the ENSregistration contract directly and not through the app)
- Public keys have a big space. For three-random words it is possible to generate arbitrary combinations with decent computational resources, but this doesn't amount to "reserving" it.
- For ENS, no. But for each name, a stake of 10 SNT is required, as well as the creation of a new identity (unless they interact directly with the ENS registration contract directly and not through the app)
#### Asynchronous (YES)
> Trust establishment can occur asynchronously without all conversation participants online.

18
x6.md
View File

@ -171,7 +171,7 @@ There are two phases in the initial negotiation of a 1:1 chat:
1. **Identity verification** (e.g., face-to-face contact exchange through QR code, Identicon matching). A QR code serves two purposes simultaneously - identity verification and initial bundle retrieval;
1. **Asynchronous initial key exchange**, using X3DH.
TODO: I'd consider calling the first Trust Establishment and lnik to that document
TODO: I'd consider calling the first Trust Establishment and link to that document
#### 2.4.1. Initial key exchange flow (X3DH)
@ -308,7 +308,7 @@ A peer is identified by two pieces of data:
1) An `installation-id` which is generated upon creating a new account in the `Status` application
2) Their identity whisper key
## 3.1 Initializiation
## 3.1 Initialization
A new session is initialized once a successful X3DH exchange has taken place.
Subsequent messages will use the established session until re-keying is necessary.
@ -421,7 +421,7 @@ TODO: description here
- Yes.
- Assuming a user validates (TODO: Check this assumption) every message they are able to decrypt and validates its signature from the sender, then it is not able to be altered in transit.
* [igorm] i'm really not sure about it, Whisper provides a signature, but I'm not sure we check it anywhere (simple grepping didn't give anything)
* [andrea] Whisper checks the signature and a public key is derived from it, we check the public key is a meaningful public key. The pk itself is not in the content of the message for public chats/1-to-1 so potentially you could send a message from a random account without having access to the private key, but that would not be much of a deal, as you might just as easilly create a random account)
* [andrea] Whisper checks the signature and a public key is derived from it, we check the public key is a meaningful public key. The pk itself is not in the content of the message for public chats/1-to-1 so potentially you could send a message from a random account without having access to the private key, but that would not be much of a deal, as you might just as easily create a random account)
#### Authentication (YES)
> Each participant in the conversation receives proof of possession of a known long-term secret from all other participants that they believe to be participating in the conversation. In addition, each participant is able to verify that a message was sent from the claimed source
@ -456,7 +456,7 @@ TODO: description here
[Andrea: This is not true, (Perfect) Forward Secrecy does not imply backward secrecy (which is also called post-compromise security, as signal calls it, or future secrecy, it's not well defined). Technically this is a NO , double ratchet offers good Backward secrecy, but not perfect. Effectively if all the key material is compromised, any future message received will be also compromised (due to the hash ratchet), until a DH ratchet step is completed (i.e. the compromised party generate a new random key and ratchet)]
#### Anonymity Preserving (PARTIAL)
> Any anonymity features provided by the underlying transport privacy architecture are not undermined (e.g., if the transport privacy system provides anonymity, the conversation security level does not deanonymize users by linking key identifiers).
> Any anonymity features provided by the underlying transport privacy architecture are not undermined (e.g., if the transport privacy system provides anonymity, the conversation security level does not de-anonymize users by linking key identifiers).
- by default, yes
- ENS Naming system attaches an identifier to a given public key
@ -466,7 +466,7 @@ TODO: description here
- We use Lamport timestamps for ordering of events.
- In addition to this, we use local timestamps to attempt a more intuitive ordering. [Andrea: currently this was introduced as a regression during performance optimization and might result in out-of-order messages if sent across day boundaries, so I consider it a bug and not part of the specs (it does not make the order more intuitive, quite the opposite as it might result in causally related messages being out-of-order, but helps dividing the messages in days)]
- Fundamentally, there's no single source of truth, nor consensus process for global ordering [Andrea: Global ordering does not need a consensus process i.e. if you order messages alphabetically, and you break ties consistenly, you have global ordering, as all the participants will see the same ordering (as opposed to say order by the time the message was received locally), of course is not useful, you want to have causal + global to be meaningful]
- Fundamentally, there's no single source of truth, nor consensus process for global ordering [Andrea: Global ordering does not need a consensus process i.e. if you order messages alphabetically, and you break ties consistently, you have global ordering, as all the participants will see the same ordering (as opposed to say order by the time the message was received locally), of course is not useful, you want to have causal + global to be meaningful]
TODO: Understand how this is different from Global Transcript
[Andrea: This is basically Global transcript for a single participants, we offer global transcript]
@ -507,7 +507,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
#### Computational Equality (YES)
> All chat participants share an equal computational load
- One a message is sent, all participanats in a group chat perform the same steps to retrieve and decrypt it.
- One a message is sent, all participants in a group chat perform the same steps to retrieve and decrypt it.
- If proof of work is actually used at the Whisper layer (basically turned off in Status) then the sender would have to do additional computational work to send messages.
#### Trust Equality (PARTIAL)
@ -515,7 +515,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
- 1:1 chats and public chats are equal
- group chats have admins (on purpose)
- Private Group chats have Administrators and Members. Upon construction, the creator is made an admin. These groups have the following priveledges:
- Private Group chats have Administrators and Members. Upon construction, the creator is made an admin. These groups have the following privileges:
- Admins:
- Add group members
- Promote group members to admin
@ -528,7 +528,7 @@ TODO: Verify if this can be done already by looking at Lamport clock difference
- Invited people don't opt-in to being invited
TODO: Group chat dynamics should have a documented state diagram
TODO: create issues for identity leak of invited members as well as current members of a group showing up who have not accepted yet [Andrea: that's an interesting point, didn't think of that. Currently we have this behaviour for 2 reasons, backward compatibility with previous releases, which had no concept of joining, and also because we rely on other peers to propagate group info, so we don't have a single-message point of failure (the invitation), the first can be addressed easilly, the second is trickier, without giving up the propagation mechanism (if we choose to give this up, then it's trivial)]
TODO: create issues for identity leak of invited members as well as current members of a group showing up who have not accepted yet [Andrea: that's an interesting point, didn't think of that. Currently we have this behavior for 2 reasons, backward compatibility with previous releases, which had no concept of joining, and also because we rely on other peers to propagate group info, so we don't have a single-message point of failure (the invitation), the first can be addressed easily, the second is trickier, without giving up the propagation mechanism (if we choose to give this up, then it's trivial)]
#### Subgroup Messaging (NO)
> Messages can be sent to a subset of participants without forming a new conversation
@ -588,4 +588,4 @@ TODO: this requires more detail
- The protocol requires whisper relay servers and mailservers currently.
- The larger the number of whisper relay servers, the better the transport security but there might be potential scaling problems.
- Mailservers act to provide asyncronicity so users can retreive messages after coming back from an offline period.
- Mailservers act to provide asynchronicity so users can retrieve messages after coming back from an offline period.

305
x7.md
View File

@ -9,66 +9,13 @@ created: 2019-04-18
updated:
---
## Introduction
# Initial Transport Privacy through Whisper Specification
## Requirements
## Table of Contents
TODO: Elaborate on requirement such as devp2p and possibly Whisper, and geth/parity/nimbus gotchas.
## Design goals
TODO: Elaborate on selection of design goals such as
Privacy
Sender Anonymity
Recipient Anonymity
Particip. Anonymity
Unlinkability
Global Adv. Resistant
Usability
Contact Discovery
No Message Delays
No Message Drops
Easy Initialization
No Fees Required
Adoption
Topology Independent
No Additional Service
Spam/Flood Resistant
Low Storage
Low Bandwidth
Low Computation
Asynchronous
Scalable
NOTE: We are probably not fulfilling all of these very well, and this is something we can note as well. "Ideally such a layer would provide...currently this isn't doing and we are doing further research into better options."
# Raw import from previous document
**TODO: Specify transport privacy through Whisper and guarantees**
See https://notes.status.im/sDKuBAiPSH6iB9cFmEKLyg?both# for things that we want to capture here.
*NOTE: Using Adam's initial spec as a starting point*
**TODO: Remove non transport privacy layer aspects here**
Status Secure Messaging Protocol
==================================================
- [Status Secure Messaging Protocol](#status-secure-messaging-protocol)
- [Abstract](#abstract)
- [Terminology](#terminology)
- [Basic Assumption](#basic-assumption)
- [Protocol Overview](#protocol-overview)
- [Payload](#payload)
- [Content types](#content-types)
- [Message types](#message-types)
- [Clock vs Timestamp and message ordering](#clock-vs-timestamp-and-message-ordering)
- [Replies](#replies)
- [Whisper adapter](#whisper-adapter)
- [Whisper node configuration](#whisper-node-configuration)
- [Keys management](#keys-management)
@ -135,72 +82,13 @@ Offline messaging describes how the protocol handles delivering messages when on
The protocol does not specify additional things like peers discovery, running Whisper nodes, underlying p2p protocols etc.
# Payload
Payload is an array of bytes exchanged between peers. In the case of this protocol, the payload is encoded using [transit format](https://github.com/cognitect/transit-format). It is a text-based format so even encoded version is easily readable by humans.
Payload contains the following fields:
1. text `string`
2. content type `enum { text/plain }` (more in [Content types](#content-types))
3. message type `enum { public-group-user-message, user-message, group-user-message }` (more in [Message types](#message-types))
4. clock `int64`
5. timestamp `int64`
6. content `struct { chat-id string, text string }`
Example of a valid encoded payload:
```
["~#c4",["abc123","text/plain","~:public-group-user-message",154593077368201,1545930773682,["^ ","~:chat-id","testing-adamb","~:text","abc123"]]]
```
As you can see, the message is an array and each index value has its meaning:
* 0: `c4` is a decoder handler identification for the current payload format. Identifications allow to register handlers for many different types of payload
* 1: array which items correspond to the described payload fields above
For more details regarding serialization and deserialization please consult [transit format](https://github.com/cognitect/transit-format) specification.
## Content types
Content types are required for a proper interpretation of incoming messaages. Not each message is a plain text but may carry a different information.
The following content types MUST be supported:
* `text/plain` identifies a message which content is a plain text
* `sticker` TODO
* `status` TODO
* `command` TODO
* `command-request` TODO
* `emoji` TODO
TODO: select which are required and which are client-specific.
## Message types
Message types are required to decide how a particular message is encrypted (more in [Whisper > Message encryption](#message-encryption)) and what metadata needs to be attacjed (more in [Whisper > Topic](#topic)) when passing a message to the transport layer.
The following messages types MUST be supported:
* `public-group-user-message` is a message to the public group
* `user-message` is a private message
* `group-user-message` is a message to the private group.
## Clock vs Timestamp and message ordering
`timestamp` MUST be Unix time calculated when the message is created. Because the peers in the Whisper network should have synchronized time, `timestamp` values should be fairly accurate among all Whisper network participants.
`clock` SHOULD be calculated using the algorithm of [Lamport timestamps](https://en.wikipedia.org/wiki/Lamport_timestamps). When there are messages available in a chat, `clock`'s value is calculated based on the last received message in a particular chat: `last-message-clock-value + 1`. If there are no messages, `clock` is initialized with `timestamp`'s value.
`clock` value is used for the message ordering. Due to the used algorithm and distributed nature of the system, we achieve casual ordering which might produce counterintuitive results in some edge cases. For example, when one joins a public chat and sends a message before receiving the exist messages, their message `clock` value might be lower and the message will end up in the past when the historical messages are fetched.
## Replies
TBD
# Whisper adapter
Whisper in version 6 has been chosen as an messages exchange protocol because it was designed as an off-chain communication layer for the Ethereum nodes. It supports e2e encryption and uses epidemic spread to route data to all members of the network. It also provides [darkness to some extent](https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness).
Whisper in version 6 has been chosen as a messages exchange protocol because it was designed as an off-chain communication layer for the Ethereum nodes. It supports e2e encryption and uses epidemic spread to route data to all members of the network. It also provides [darkness to some extent](https://github.com/ethereum/go-ethereum/wiki/Achieving-Darkness).
However, using Whisper has a few tradeoffs:
* was not designed to handle huge number of messages
* was not designed to be real-time; some delays over a few seconods are expected
* was not designed to be real-time; some delays over a few seconds are expected
* does not scale well with the number of messages in the network
This protocol can operate using a Whisper service which requires this protocol implementation to run in the same process as well as Whisper's RPC API which might be provided by a separate Whisper node process via IPC or WebSocket.
@ -211,7 +99,7 @@ There is some tight coupling between the payload and Whisper:
## Whisper node configuration
If you want to run a Whisper node and receive messages from Status clients, it must be properly cnofigured.
If you want to run a Whisper node and receive messages from Status clients, it must be properly configured.
Whisper's Proof Of Work algorithm is used to deter denial of service and various spam/flood attacks against the Whisper network. The sender of a message must perform some work which in this case means processing time. Because Status' main client is a mobile client, this easily leads to battery draining and poor performance of the app itself. Hence, all clients MUST use the following Whisper node settings:
* proof-of-work not larger than `0.002`
@ -233,7 +121,7 @@ Keys management for PFS is described in [Perfect forward secrecy section](#perfe
All encryption algorithms used by Whisper should be described in the [Whisper V6 specification](http://eips.ethereum.org/EIPS/eip-627).
Cryptographic algoritms used by PFS are described in [Perfect forward secrecy section](#perfect-forward-secrecy-pfs).
Cryptographic algorithms used by PFS are described in [Perfect forward secrecy section](#perfect-forward-secrecy-pfs).
## Topic
@ -287,7 +175,7 @@ As not all messages are encrypted with PFS, a following strategy MAY be used:
2. Try to decrypt the message payload using PFS algorithm
2.1. If successful, pass the decrypted value to (3)
2.2. If failed, pass the unchanged payload to (3)
3. Decode the payload as described in [Paylooad](#payload) section
3. Decode the payload as described in [Payload](#payload) section
TODO: link to a separate document (currently in the PR).
@ -299,7 +187,7 @@ TODO: link to a separate document.
# One-to-one messages
One-to-one messages are also known as private messages. These are the messages sent beween two participants of the conversation.
One-to-one messages are also known as private messages. These are the messages sent between two participants of the conversation.
## Sending
@ -322,7 +210,7 @@ Learn more following [Whisper V6 RPC API](https://github.com/ethereum/go-ethereu
### Sending using PFS
When one decides to use PFS, the flow is the same but the payload MUST be additionally encrypted following the [PFS specification](#pfs) before being hex-endoded and passed to `shh_post`.
When one decides to use PFS, the flow is the same but the payload MUST be additionally encrypted following the [PFS specification](#pfs) before being hex-encoded and passed to `shh_post`.
## Receiving
@ -342,7 +230,7 @@ Learn more following [Whisper V6 RPC API](https://github.com/ethereum/go-ethereu
Public messages are encrypted with a symmetric key which is publicly known so anyone can participate in the conversation.
The fact that anyone can participate makes the public chats voulnerable to spam attacks. Also, there are no moderators of these chats.
The fact that anyone can participate makes the public chats vulnerable to spam attacks. Also, there are no moderators of these chats.
## Sending
@ -408,12 +296,7 @@ All described addons are implemented in [status-im/whisper fork](https://github.
## New RPC methods
TODO: provide a list of RPC methods from `shhext` API which are relevant to this spec.
## Raw SoK message evaluation
*TODO: Write this in a more active voice and with a better structure.**
<!--TODO: provide a list of RPC methods from `shhext` API which are relevant to this spec.-->
## Transport privacy
@ -424,165 +307,7 @@ This evaluates Whisper as a standalone protocol. However, we also note common us
- [EIP-627, aka Whisper v6](https://eips.ethereum.org/EIPS/eip-627)
- [Whisper PoC 2 spec (more motivation)](https://github.com/ethereum/wiki/wiki/Whisper-PoC-2-Protocol-Spec)
### --- Privacy
#### Sender Anonymity (PARTIAL)
> When a chat message is received, no non-global entities except for the sender can determine which entity produced the message.
- Generally speaking, a peer can't tell if a neighbor is the message originator.
- However, since the "signature" of an envelope doesn't change, this means a Global Passive Adversary can watch a packet as it traverses the network.
- Additionally, being fully surrounded by cooperating adverserial nodes breaks this. This is similar to an eclipse attack, since these nodes can cooperate and distinguish between relaying messages and new messages.
- Light clients that don't repeat traffic will leave more obvious metadata trail.
- Using a mix format would partially mitigate this, e.g. [Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf)
- Moot account
- All messages are signed by (identity) private key that can be generated at will, which provides pseudonymity. The Moot account is a shared key. The more people that use it, the larger the anonymity set is.
- potential for hard coding it into app for increasing its anonymity set
#### Recipient Anonymity (YES)
> No non-global entities except the receiver of a chat message know which entity received it.
- One caveat is that if you listen to too specialized topics you might give up too much information. This is a trade-off with bandwidth consumption.
- 1:1 chats are currently under one topic, but will be partitioned (somehow)
- ask Roman [IGOR: partitioning was implemented, a few topics are generated from each user's public keys]
- We are working with an optional ACK message to verify receipt of message
* [IGOR] only from mailservers
- The various types of chat we provide right now are:
- 1:1 chat
- Private group chat
- Public chats
- Since Whisper is broadcast based, we use topics for this. This ensures the bandwidth usage is somewhat more managable, trading off darkness.
- Public chats are hashed to a topic. Then we have a special discovery topic, which we use to coordinate further topics. E.g. for group chat there's a a secret, random topic that's agreed upon for further communication. 1:1 currently uses discovery topic, but you can either partition this or use things like topic ratcheting. This is at the expense of some more coordination, similar to how you generate a shared secret key.
#### Participant Anonymity (YES)
> No non-global entities except the conversation participants can discover which set of network nodes are engaged in a conversation
- See Conversation Security
#### Unlinkability (YES)
> No non-global entities except the conversation participants can discover that two protocol messages belong to the same conversation.
- Since it is broadcast based, there's no unique recipient.
- (This might change depending on topic usage).
#### Global Adversary Resistant (NO)
> Global adversaries cannot break the anonymity of the protocol
- Sender anonymity is broken if an envelope has a unique signature, as well as in the abovementioned eclipse-like attack.
### --- Usability
#### Contact Discovery (YES)
> The system provides a mechanism for discovering contact information.
- A "contact" identifier in Whisper is a public-key. You can get this via a few methods
- out of band
- in-band in a public chat
- ENS naming scheme
- Assuming you have a public key, you can contact them.
##### Notes
For a mixnet based approach, see e.g. https://github.com/w3f/messaging/issues/22
#### No Message Delays (YES)
> No long message delays are incurred.
- No real time communication but assuming reasonable node connectivity the number of relays is a low constant.
#### No Message Drops (NO)
> No Message Drops: Dropped messages are retransmitted.
- Whisper messages have a TTL
- With Whisper mailserver extensions expired messages can be received through a direct TCP connection over some timeframe.
#### Easy Initialization (YES)
> The user does not need to perform any significant tasks before starting to communicate.
- True.
#### No Fees Required (YES)
> The scheme does not require monetary fees to be used.
- True.
[Igor: how does that matches with Network Incentivization? Woudn't it break this?]
### --- Adoption
#### Topology independent (YES)
> No network topology is imposed on the conversation security or trust establishment schemes
- The topology has no impact on the security of the network
##### Notes
-https://github.com/w3f/messaging/issues/12
#### No Additional Services (YES*)
> The architecture does not depend on availability of any infrastructure beyond the chat participants.
- Technically nothing breaks if only the participants are relaying Whisper messages, but some of the security assumptions are based on a broader userbase
#### Spam/Flood Resistant (PARTIAL)
> The availability of the system is resistant to denial-of-service attacks and bulk messaging
- Proof of work produces a nonce based on payload and TTL. However, this doesn't take heterogenerous devices into account.
- For Status this is a NO since PoW is set arbitrarily low.
#### Low Storage (NO)
> The system does not require a large amount of storage capacity for any entity
- Entities receive messages they don't "need". However, there's no requirement for individual nodes to keep messages or write to disk.
- Storage requirement of entire network of N nodes for M messages can be up to M*TTL*N.
#### Low Bandwidth (NO)
> The system does not require a large amount of bandwidth usage for any entity.
- You receive messages you don't need, by relaying, also redundantly.
- It's a flood-like network.
- Use of bloom filters and partial relaying (light mode of operation) reduces this somewhat, at the expense of weaker privacy guarantees.
##### Notes
- Compare redundant messages in Whisper vs PSS: https://status.im/research/whisper_pss.html
#### Low Computation (NO)
> The system does not require a large amount of processing power for any entity
- Must attempt to decrypt every message received on the network, also must provide PoW to send
#### Asynchronous (NO)
> Messages sent to recipients who are offline will be delivered when the recipient reconnects, even if the sender has since disconnected.
- There's a TTL for each message.
- As an extension, there's a Whisper mailserver that resend messages on demand to trusted peers. However, this happens outside of the normal Whisper transport through a direct TCP connection. [Andrea: I am not sure this is accurate, first whisper uses TCP and direct connections to any peer (through devp2p). the request happens at the devp2p channel, which is the one whisper uses to communicate, and the sending of envelopes is not much different from other peers, although this envelopes are different (might be expired, but we accept them as the peer is trusted), but the mailserver is a peer (although a trusted one) Dshulyak can help out to confirm, but it seems that the point is debatable]
#### Scalable (NO)
> The amount of resources required to maintain system availability scales linearly with the number of users.
- It's :whale: worse than linear, as every additional user must carry the load of all other users.
- The trade-off of partitioning the network is losing security around dark routing of messages.
- This trade-off appears suboptimal.
- Peer steering: https://github.com/ethereum/wiki/wiki/Whisper-PoC-2-Protocol-Spec
<!-- TODO: Document Discovery topic -->
<!-- TODO: Document topic hashing for 1:1 chat -->
<!-- TODO: Document topic hashing for private group chat -->
<!-- TODO: Document topic hashing for public chats -->

10
x8.md
View File

@ -14,7 +14,7 @@ updated:
This specification describes how the payload of each message in the Status Protocol looks like. It does not care how the payload is encrypted or exchanged later.
The payload must be flexible enough to support messenging but also cases described in [Status Whitepaper](https://status.im/whitepaper.pdf) as well as various clients created using vastly different technologies.
The payload must be flexible enough to support messaging but also cases described in [Status Whitepaper](https://status.im/whitepaper.pdf) as well as various clients created using vastly different technologies.
# Wrapper
@ -31,7 +31,7 @@ record:
Where `signature` is the bytes of the signed `SHA3-256` of the payload, signed with
the key of the author of the message.
The signature is needed to validate authorship of the message, so that the message can be relayed to third parties.
If a signature is not present but an author is provided by a layer below, the message is to be relayed to third parties and it's considered plausibly deniable.
If a signature is not present but an author is provided by a layer below, the message is to be relayed to third parties and its considered plausibly deniable.
# Encoding
@ -65,7 +65,7 @@ The type `Message` represents a text message exchanged between clients.
### Payload
Payload is a struct (a compound data type) with the following fields (order is importent):
Payload is a struct (a compound data type) with the following fields (order is important):
1. text `string`
2. content type `enum` (more in [Content types](#content-types))
3. message type `enum` (more in [Message types](#message-types))
@ -76,7 +76,7 @@ Payload is a struct (a compound data type) with the following fields (order is i
### Content types
Content types are required for a proper interpretation of incoming messaages. Not each message is a plain text but may carry a different information.
Content types are required for a proper interpretation of incoming messages. Not each message is a plain text but may carry a different information.
The following content types MUST be supported:
* `text/plain` identifies a message which content is a plain text.
@ -90,7 +90,7 @@ There are also other content types that MAY be implemented by the client:
### Message types
Message types are required to decide how a particular message is encrypted (more in [Whisper > Message encryption](#message-encryption)) and what metadata needs to be attacjed (more in [Whisper > Topic](#topic)) when passing a message to the transport layer.
Message types are required to decide how a particular message is encrypted (more in [Whisper > Message encryption](#message-encryption)) and what metadata needs to be attached (more in [Whisper > Topic](#topic)) when passing a message to the transport layer.
The following messages types MUST be supported:
* `public-group-user-message` is a message to the public group

2
x9.md
View File

@ -32,7 +32,7 @@ Everything else associated with the contact is either verified or derived from t
- one-time prekey: $OPK$ (???? need this?)
## 2 Account Broadcasting
- A user is reponsible for broadcasting certain information publicly so that others may contact them.
- A user is responsible for broadcasting certain information publicly so that others may contact them.
### 2.1 X3DH Prekey bundles
- A client [MUST/SHOULD] regenerate a group of X3DH prekey bundles every 24 hours and broadcast them through the appropriate channels