mirror of https://github.com/status-im/specs.git
remove more fluff
This commit is contained in:
Oskar Thoren
parent
d817fb2edc
commit
c0a9be3e54
173
x7.md
173
x7.md
|
|
@ -361,12 +361,7 @@ All described addons are implemented in [status-im/whisper fork](https://github.
|
||||||
|
|
||||||
## New RPC methods
|
## New RPC methods
|
||||||
|
|
||||||
TODO: provide a list of RPC methods from `shhext` API which are relevant to this spec.
|
<!--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.**
|
|
||||||
|
|
||||||
## Transport privacy
|
## Transport privacy
|
||||||
|
|
||||||
|
|
@ -377,165 +372,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)
|
- [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)
|
- [Whisper PoC 2 spec (more motivation)](https://github.com/ethereum/wiki/wiki/Whisper-PoC-2-Protocol-Spec)
|
||||||
|
|
||||||
### --- Privacy
|
<!-- TODO: Document Discovery topic -->
|
||||||
|
<!-- TODO: Document topic hashing for 1:1 chat -->
|
||||||
#### Sender Anonymity (PARTIAL)
|
<!-- TODO: Document topic hashing for private group chat -->
|
||||||
> When a chat message is received, no non-global entities except for the sender can determine which entity produced the message.
|
<!-- TODO: Document topic hashing for public chats -->
|
||||||
|
|
||||||
- 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 adversarial 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 manageable, 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 above mentioned 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 heterogeneous 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
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue