mirror of https://github.com/status-im/specs.git
remove whisper adapter stuff from x7
This commit is contained in:
Oskar Thoren
parent
6b0c9c9034
commit
cad6d5f3de
82
x7.md
82
x7.md
|
|
@ -67,88 +67,6 @@ 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.
|
||||
|
||||
# Whisper adapter
|
||||
|
||||
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 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.
|
||||
|
||||
There is some tight coupling between the payload and Whisper:
|
||||
* Whisper message topic depends on the actual message type (see [Topic](#topic))
|
||||
* Whisper message uses a different key (asymmetric or symmetric) depending on the actual message type (see [Keys management](#keys-management))
|
||||
|
||||
## Whisper node configuration
|
||||
|
||||
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`
|
||||
* time-to-live not lower than `10` (in seconds)
|
||||
|
||||
TODO: provide an instruction how to start a Whisper node with proper configuration using geth.
|
||||
|
||||
## Keys management
|
||||
|
||||
The protocol requires a key (symmetric or asymmetric) for the following actions:
|
||||
* signing a message (a private key)
|
||||
* decrypting received messages (a private key or symmetric key).
|
||||
|
||||
As private keys and symmetric keys are required to process incoming messages, they must be available all the time and are stored in memory.
|
||||
|
||||
Keys management for PFS is described in [Perfect forward secrecy section](#perfect-forward-secrecy-pfs).
|
||||
|
||||
## Encryption algorithms
|
||||
|
||||
All encryption algorithms used by Whisper should be described in the [Whisper V6 specification](http://eips.ethereum.org/EIPS/eip-627).
|
||||
|
||||
Cryptographic algorithms used by PFS are described in [Perfect forward secrecy section](#perfect-forward-secrecy-pfs).
|
||||
|
||||
## Topic
|
||||
|
||||
There are two types of Whisper topics the protocol uses:
|
||||
* static topic for `user-message` message type (also called _contact discovery topic_)
|
||||
* dynamic topic based on a chat name for `public-group-user-message` message type.
|
||||
|
||||
The static topic is always the same and its hex representation is `0xf8946aac`. In fact, _the contact discovery topic_ is calculated using a dynamic topic algorithm described below with a constant name `contact-discovery`.
|
||||
|
||||
Having only one topic for all private chats has an advantage as it's very hard to figure out who talks to who. A drawback is that everyone receives everyone's messages but they can decrypt only these they have private keys for.
|
||||
|
||||
A dynamic topic is derived from a string using the following algorithm:
|
||||
|
||||
```
|
||||
var hash []byte
|
||||
|
||||
hash = keccak256(name)
|
||||
|
||||
# Whisper V6 specific
|
||||
var topic [4]byte
|
||||
|
||||
topic_len = 4
|
||||
|
||||
if len(hash) < topic_len {
|
||||
topic_len = len(hash)
|
||||
}
|
||||
|
||||
for i = 0; i < topic_len; i++ {
|
||||
topic[i] = hash[i]
|
||||
}
|
||||
```
|
||||
|
||||
## Message encryption
|
||||
|
||||
The protocol distinguishes messages encrypted using asymmetric and symmetric encryption.
|
||||
|
||||
Symmetric keys are created using [`shh_generateSymKeyFromPassword`](https://github.com/ethereum/go-ethereum/wiki/Whisper-v6-RPC-API#shh_generatesymkeyfrompassword) Whisper V6 RPC API method which accepts one param, a string.
|
||||
|
||||
Messages encrypted with asymmetric encryption should be encrypted using recipient's public key so that only the recipient can decrypt them.
|
||||
|
||||
Encryption of messages supporting PFS is described in [Perfect Forward Secrecy](#perfect-forward-secrecy-pfs) section.
|
||||
|
||||
# Perfect Forward Secrecy (PFS)
|
||||
|
||||
Additionally to encrypting messages on the Whisper level, the protocol supports PFS specification.
|
||||
|
|
|
|||
Loading…
Reference in New Issue