status-im/specs
2
0
Fork 0
mirror of https://github.com/status-im/specs.git synced 2025-02-05 02:43:36 +00:00
Code Issues Projects Releases Wiki Activity

removes fluff

Browse Source
This commit is contained in:
decanus 2019-08-26 15:19:21 +02:00
parent 4c42d1e886
commit 804ce70255
No known key found for this signature in database
GPG Key ID: E95B8C69228FF5B4
1 changed files with 13 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
x4.md
View File

@ -3,14 +3,14 @@ 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
@ -32,7 +32,7 @@ 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.
@ -40,23 +40,18 @@ The well-defined format also makes it possible to support multiple types of conv
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.
# Conversational Security Layer
Conversational Security Layer provides various cryptographical properties to the Status Protocol:
* confidentiality
* integrity
* authentication
* forward secrecy.
Conversational Security Layer provides various cryptographical properties:
Confidetiality makes sure that only intended recipients are able to read a message.
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.
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.
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.