diff --git a/fetch-content.js b/fetch-content.js index 1b3f80b..553cc01 100644 --- a/fetch-content.js +++ b/fetch-content.js @@ -181,7 +181,7 @@ function parseSlugFromFrontmatter(content) { } function unescapeHtmlComments(htmlString) { - return htmlString.replace(/\\<\!--/g, '') + return htmlString.replace(/\\<\!--/g, '\n\n') } async function downloadAndSaveFile(url, filePath) { diff --git a/nomos/claro.md b/nomos/claro.md index c275a4c..aebf541 100644 --- a/nomos/claro.md +++ b/nomos/claro.md @@ -123,7 +123,10 @@ The algorithm is divided into 4 phases: 3. Transition function 4. Opinion and Decision + + + + ### Setup Parameters The node initializes the following integer ratios as constants: diff --git a/status/1to1-chat.md b/status/1to1-chat.md index a709828..4c42d14 100644 --- a/status/1to1-chat.md +++ b/status/1to1-chat.md @@ -145,7 +145,9 @@ message MembershipUpdateEvent { } } ``` + + Note that the definitions for `ChatMessage` and `EmojiReaction` can be found in [chat_message.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/chat_message.proto#L1) and [emoji_reaction.proto](https://github.com/status-im/status-go/blob/5fd9e93e9c298ed087e6716d857a3951dbfb3c1e/protocol/protobuf/emoji_reaction.proto). ##### Chat Created diff --git a/status/71/images/notification.png b/status/71/images/notification.png index 961fdee..9b9db63 100644 Binary files a/status/71/images/notification.png and b/status/71/images/notification.png differ diff --git a/status/account-address.md b/status/account-address.md index d98e9d4..9d78bfc 100644 --- a/status/account-address.md +++ b/status/account-address.md @@ -56,8 +56,10 @@ The Status node verifies or derives everything else associated with the contact ### User Profile Picture - An account MAY edit the `IK` generated identicon with a chosen picture. This picture will become part of the publicly broadcasted profile of the account. + + ## Wire Format Below is the wire format for the account information that is broadcasted publicly. diff --git a/status/communities.md b/status/communities.md index 4db3310..639a598 100644 --- a/status/communities.md +++ b/status/communities.md @@ -74,6 +74,7 @@ The following cryptographic primitives are used in the design - ## Wire format + + ```protobuf syntax = "proto3"; @@ -317,7 +319,9 @@ contentTopic = "/waku/1/0x" + topic + "/rfc26" #### Community channels/chats The unique identifier for a community channel/chat is the chat id. + + The content topic that Community channels/chats use MUST be the hex-encoded keccak-256 hash of the public key of the community concatenated with the chat id. ``` @@ -365,7 +369,9 @@ The flows for Community management are as described below. 1. The Community owner generates a public/private key pair. 2. The Community owner configures the Community metadata, according to the wire format "CommunityDescription". 3. The Community owner publishes the Community metadata on a content topic derived from the public key of the Community. -the Community metadata SHOULD be encrypted with the public key of the Community. +the Community metadata SHOULD be encrypted with the public key of the Community. + + The Community metadata MAY be sent during fixed intervals, to ensure that the Community metadata is available to members. The Community metadata SHOULD be sent every time the Community metadata is updated. 4. The Community owner MAY advertise the Community out of band, by sharing the public key of the Community on other mediums of communication. diff --git a/status/keycard-usage.md b/status/keycard-usage.md index d9be8b6..3cdac9c 100644 --- a/status/keycard-usage.md +++ b/status/keycard-usage.md @@ -248,9 +248,11 @@ To verify the pin of the keycard. Status code reference: - 3: PIN is valid + + ### 9. Change the pin (`/change-pin`) To change the pin of the keycard. diff --git a/status/payloads.md b/status/payloads.md index 6dd18f7..5e9cd70 100644 --- a/status/payloads.md +++ b/status/payloads.md @@ -286,9 +286,11 @@ message DiscordMessageAttachment { A node requires message types to decide how to encrypt a particular message and what metadata needs to be attached when passing a message to the transport layer. For more on this, see [10/WAKU2](../../waku/standards/core/10/waku2.md). + + The following messages types MUST be supported: * `ONE_TO_ONE` is a message to the public group * `PUBLIC_GROUP` is a private message diff --git a/vac/mvds.md b/vac/mvds.md index 172b889..5908893 100644 --- a/vac/mvds.md +++ b/vac/mvds.md @@ -114,8 +114,10 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT 3. When a node receives an `ACK`, the `MESSAGE` is removed from the state for the given peer. 4. All records that require retransmission are added to the payload, given `Send Epoch` has been reached. + + \

\ \
@@ -125,8 +127,10 @@ Nodes MAY have two modes with which they can send records: `BATCH` and `INTERACT \> ***NOTE:** Batch mode is higher bandwidth whereas interactive mode is higher latency.* + + ### Retransmission The record of the type `Type` SHOULD be retransmitted every time `Send Epoch` is smaller than or equal to the current epoch. diff --git a/vac/remote-log.md b/vac/remote-log.md index d3b1c7f..78fb1ea 100644 --- a/vac/remote-log.md +++ b/vac/remote-log.md @@ -33,8 +33,10 @@ content addressed storage, or the name system. It is assumed these capabilities are abstracted away in such a way that any such protocol can easily be implemented. + + ### Payloads Payloads are implemented using [protocol buffers v3](https://developers.google.com/protocol-buffers/). @@ -60,8 +62,10 @@ message Content { } ``` + + **NS service**: ```protobuf @@ -92,9 +96,13 @@ message Response { } ``` + + + + **Remote log:** ```protobuf @@ -114,10 +122,14 @@ message RemoteLog { } ``` + + + + ## Synchronization ### Roles @@ -133,21 +145,29 @@ The *remote log* protobuf is what is stored in the name system. "Bob" can represent anything from 0 to N participants. Unlike Alice, Bob only needs read-only access to NS and CAS. + + + + ### Flow + + \

\ \
Figure 1: Remote log data synchronization. \ + + ### Remote log The remote log lets receiving nodes know what data they are missing. Depending @@ -202,10 +222,14 @@ log. The latter is useful for things like backups on durable storage. The pointer to the 'next page' is another remote log entry, at a previous point in time. + + + + ### Interaction with MVDS [vac.mvds.Message](../2/mvds.md/#payloads) payloads are the only payloads that MUST be uploaded. Other messages types MAY be uploaded, depending on the implementation. diff --git a/waku/informational/30/images/adaptive_node_continuum.jpg b/waku/informational/30/images/adaptive_node_continuum.jpg index c675011..ae7a4fb 100644 Binary files a/waku/informational/30/images/adaptive_node_continuum.jpg and b/waku/informational/30/images/adaptive_node_continuum.jpg differ diff --git a/waku/informational/30/images/adaptive_node_continuum2.png b/waku/informational/30/images/adaptive_node_continuum2.png index 2a77b0d..dceecfc 100644 Binary files a/waku/informational/30/images/adaptive_node_continuum2.png and b/waku/informational/30/images/adaptive_node_continuum2.png differ diff --git a/waku/informational/30/images/adaptive_node_cross_section.jpg b/waku/informational/30/images/adaptive_node_cross_section.jpg index ebadfa5..4685dbb 100644 Binary files a/waku/informational/30/images/adaptive_node_cross_section.jpg and b/waku/informational/30/images/adaptive_node_cross_section.jpg differ diff --git a/waku/informational/30/images/adaptive_node_cross_section2.png b/waku/informational/30/images/adaptive_node_cross_section2.png index 59e4ed3..266a09b 100644 Binary files a/waku/informational/30/images/adaptive_node_cross_section2.png and b/waku/informational/30/images/adaptive_node_cross_section2.png differ diff --git a/waku/informational/30/images/adaptive_node_network_topology_protocols2.png b/waku/informational/30/images/adaptive_node_network_topology_protocols2.png index 0c57b2c..548f36c 100644 Binary files a/waku/informational/30/images/adaptive_node_network_topology_protocols2.png and b/waku/informational/30/images/adaptive_node_network_topology_protocols2.png differ diff --git a/waku/informational/30/images/adaptive_node_network_topology_protocols_legend.png b/waku/informational/30/images/adaptive_node_network_topology_protocols_legend.png index 283c05b..eb23f55 100644 Binary files a/waku/informational/30/images/adaptive_node_network_topology_protocols_legend.png and b/waku/informational/30/images/adaptive_node_network_topology_protocols_legend.png differ diff --git a/waku/informational/30/images/adaptive_node_protocol_selection2.png b/waku/informational/30/images/adaptive_node_protocol_selection2.png index fb8f0b9..89c527f 100644 Binary files a/waku/informational/30/images/adaptive_node_protocol_selection2.png and b/waku/informational/30/images/adaptive_node_protocol_selection2.png differ diff --git a/waku/informational/30/images/adaptive_protocol_selection.jpg b/waku/informational/30/images/adaptive_protocol_selection.jpg index 55fefbd..0a98434 100644 Binary files a/waku/informational/30/images/adaptive_protocol_selection.jpg and b/waku/informational/30/images/adaptive_protocol_selection.jpg differ diff --git a/waku/standards/application/swap.md b/waku/standards/application/swap.md index a91f0d4..7fe0dab 100644 --- a/waku/standards/application/swap.md +++ b/waku/standards/application/swap.md @@ -177,6 +177,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public 3. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth) 4. [13/WAKU2-STORE](../../core/13/store.md) + + diff --git a/waku/standards/core/10/images/overview.png b/waku/standards/core/10/images/overview.png index 1e9eb3f..3c05c8f 100644 Binary files a/waku/standards/core/10/images/overview.png and b/waku/standards/core/10/images/overview.png differ diff --git a/waku/standards/core/12/filter.md b/waku/standards/core/12/filter.md index 58a53ae..8d01d10 100644 --- a/waku/standards/core/12/filter.md +++ b/waku/standards/core/12/filter.md @@ -145,9 +145,13 @@ implementation, though a reasonable default is one minute. --- # Future Work + + **Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: -- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor. +- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor + +. Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. - By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI). diff --git a/waku/standards/core/17/images/rln-message-verification.png b/waku/standards/core/17/images/rln-message-verification.png index 46ec558..17d69f8 100644 Binary files a/waku/standards/core/17/images/rln-message-verification.png and b/waku/standards/core/17/images/rln-message-verification.png differ diff --git a/waku/standards/core/17/images/rln-relay.png b/waku/standards/core/17/images/rln-relay.png index 285c287..faf3fac 100644 Binary files a/waku/standards/core/17/images/rln-relay.png and b/waku/standards/core/17/images/rln-relay.png differ diff --git a/waku/standards/core/filter.md b/waku/standards/core/filter.md index 1ee0ea1..ebfdf4e 100644 --- a/waku/standards/core/filter.md +++ b/waku/standards/core/filter.md @@ -234,9 +234,13 @@ and that it matches filter criteria belonging to that subscription. --- ## Future Work + + **Anonymous filter subscription**: This feature guarantees that nodes can anonymously subscribe for a message filter (i.e., without revealing their exact content filter). As such, no adversary in the `WakuFilter` protocol would be able to link nodes to their subscribed content filers. The current version of the `WakuFilter` protocol does not provide anonymity as the subscribing node has a direct connection to the full node and explicitly submits its content filter to be notified about the matching messages. However, one can consider preserving anonymity through one of the following ways: -- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor. +- By hiding the source of the subscription i.e., anonymous communication. That is the subscribing node shall hide all its PII in its filter request e.g., its IP address. This can happen by the utilization of a proxy server or by using Tor + +. Note that the current structure of filter requests i.e., `FilterRPC` does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve anonymity. - By deploying secure 2-party computations in which the subscribing node obtains the messages matching a content filter whereas the full node learns nothing about the content filter as well as the messages pushed to the subscribing node. Examples of such 2PC protocols are [Oblivious Transfers](https://link.springer.com/referenceworkentry/10.1007%2F978-1-4419-5906-5_9#:~:text=Oblivious%20transfer%20(OT)%20is%20a,information%20the%20receiver%20actually%20obtains.) and one-way Private Set Intersections (PSI). diff --git a/waku/standards/core/relay.md b/waku/standards/core/relay.md index a798b69..77f6b1d 100644 --- a/waku/standards/core/relay.md +++ b/waku/standards/core/relay.md @@ -26,11 +26,13 @@ As such the scope is limited to defining a separate [`protocol id`](https://gith The `11/WAKU2-RELAY` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model). Note that data confidentiality, integrity, and authenticity are currently considered out of scope for `11/WAKU2-RELAY` and must be handled by higher layer protocols such as [`14/WAKU2-MESSAGE`](../14/message.md). + + - **Publisher-Message Unlinkability**: This property indicates that no adversarial entity can link a published `Message` to its publisher. This feature also implies the unlinkability of the publisher to its published topic ID as the `Message` embodies the topic IDs. @@ -38,8 +40,10 @@ This feature also implies the unlinkability of the publisher to its published to - **Subscriber-Topic Unlinkability**: This feature stands for the inability of any adversarial entity from linking a subscriber to its subscribed topic IDs. + + ### Terminology _Personally identifiable information_ (PII) refers to any piece of data that can be used to uniquely identify a user. @@ -133,15 +137,19 @@ Note that this does not merely imply that these fields be empty, but that they M ## Security Analysis + + - **Publisher-Message Unlinkability**: To address publisher-message unlinkability, one should remove any PII from the published message. As such, `11/WAKU2-RELAY` follows the `StrictNoSign` policy as described in [libp2p PubSub specs](https://github.com/libp2p/specs/tree/master/pubsub#message-signing). As the result of the `StrictNoSign` policy, `Message`s should be built without the `from`, `signature` and `key` fields since each of these three fields individually counts as PII for the author of the message (one can link the creation of the message with libp2p peerId and thus indirectly with the IP address of the publisher). Note that removing identifiable information from messages cannot lead to perfect unlinkability. The direct connections of a publisher might be able to figure out which `Message`s belong to that publisher by analyzing its traffic. -The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. +The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. + + - **Subscriber-Topic Unlinkability:** To preserve subscriber-topic unlinkability, it is recommended by [`10/WAKU2`](../10/waku2.md) to use a single PubSub topic in the `11/WAKU2-RELAY` protocol. @@ -159,13 +167,17 @@ At a high level, peers utilize a scoring function to locally score the behavior `11/WAKU2-RELAY` aims at enabling an advanced spam protection mechanism with economic disincentives by utilizing Rate Limiting Nullifiers. In a nutshell, peers must conform to a certain message publishing rate per a system-defined epoch, otherwise, they get financially penalized for exceeding the rate. More details on this new technique can be found in [`17/WAKU2-RLN-RELAY`](../17/rln-relay.md). - + + + - Providing **Unlinkability**, **Integrity** and **Authenticity** simultaneously: Integrity and authenticity are typically addressed through digital signatures and Message Authentication Code (MAC) schemes, however, the usage of digital signatures (where each signature is bound to a particular peer) contradicts with the unlinkability requirement (messages signed under a certain signature key are verifiable by a verification key that is bound to a particular publisher). As such, integrity and authenticity are missing features in `11/WAKU2-RELAY` in the interest of unlinkability. In future work, advanced signature schemes like group signatures can be utilized to enable authenticity, integrity, and unlinkability simultaneously. -In a group signature scheme, a member of a group can anonymously sign a message on behalf of the group as such the true signer is indistinguishable from other group members. +In a group signature scheme, a member of a group can anonymously sign a message on behalf of the group as such the true signer is indistinguishable from other group members. + + ## Copyright diff --git a/waku/standards/core/rln-relay.md b/waku/standards/core/rln-relay.md index 97bc326..9e9fe8f 100644 --- a/waku/standards/core/rln-relay.md +++ b/waku/standards/core/rln-relay.md @@ -25,8 +25,10 @@ Peers that violate the messaging rate are considered spammers and their message Spammers are also financially punished and removed from the system. + + ## Motivation In open and anonymous p2p messaging networks, one big problem is spam resistance. @@ -50,7 +52,9 @@ The higher-level layers adopting `17/WAKU2-RLN-RELAY` MAY choose to enforce the ### Setup and Registration Peers subscribed to a specific `pubsubTopic` form a [RLN group](../../../../vac/32/rln-v1.md). + + Peers MUST be registered to the RLN group to be able to publish messages. Registration is moderated through a smart contract deployed on the Ethereum blockchain. Each peer has an [RLN key pair](../../../../vac/32/rln-v1.md) denoted by `sk` and `pk`. @@ -59,7 +63,9 @@ The state of the membership contract contains the list of registered members' pu For the registration, a peer creates a transaction that invokes the registration function of the contract via which registers its `pk` in the group. The transaction also transfers some amount of ether to the contract to be staked. This amount is denoted by `staked_fund` and is a system parameter. -The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` of the staked fund by providing valid proof. +The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` of the staked fund by providing valid proof. + + `reward_portion` is also a system parameter. Note that `sk` is initially only known to its owning peer however, it may get exposed to other peers in case the owner attempts spamming the system i.e., sending more than one message per `epoch`. @@ -92,7 +98,9 @@ The `proof` field is a zero-knowledge proof signifying that: 3. The `nullifier` is constructed correctly. For more details about the proof generation check [RLN](../../../../vac/32/rln-v1.md) The proof generation relies on the knowledge of two pieces of private information i.e., `sk` and `authPath`. -The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. +The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. + + The proof generation also requires a set of public inputs which are: the Merkle tree root `merkle_root`, the current `epoch`, and the message for which the proof is going to be generated. In `17/WAKU2-RLN-RELAY`, the message is the concatenation of `WakuMessage`'s `payload` filed and its `contentTopic` i.e., `payload||contentTopic`. @@ -153,8 +161,10 @@ The `sk` then can be used to delete the spammer from the group and withdraw a po An overview of the routing procedure and slashing is provided in Figure 2. + + ![Figure 2: Publishing, Routing and Slashing workflow.](./17/images/rln-message-verification.png) ------- @@ -198,7 +208,9 @@ Below is the description of the fields of `RateLimitProof` and their types. | ----: | ----------- | ----------- | | `proof` | array of 256 bytes | the zkSNARK proof as explained in the [Publishing process](##Publishing) | | `merkle_root` | array of 32 bytes in little-endian order | the root of membership group Merkle tree at the time of publishing the message | -| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md) | +| `share_x` and `share_y`| array of 32 bytes each | Shamir secret shares of the user's secret identity key `sk` . `share_x` is the Poseidon hash of the `WakuMessage`'s `payload` concatenated with its `contentTopic` . `share_y` is calculated using [Shamir secret sharing scheme](../../../../vac/32/rln-v1.md) | + + | `nullifier` | array of 32 bytes | internal nullifier derived from `epoch` and peer's `sk` as explained in [RLN construct](../../../../vac/32/rln-v1.md)| diff --git a/waku/standards/core/store.md b/waku/standards/core/store.md index 574b2d0..9377fd9 100644 --- a/waku/standards/core/store.md +++ b/waku/standards/core/store.md @@ -221,13 +221,21 @@ However, one can consider preserving anonymity through one of the following ways This can happen by the utilization of a proxy server or by using Tor. Note that the current structure of historical requests does not embody any piece of PII, otherwise, such data fields must be treated carefully to achieve query anonymity. - + + + - By deploying secure 2-party computations in which the querying node obtains the historical messages of a certain topic, the queried node learns nothing about the query. Examples of such 2PC protocols are secure one-way Private Set Intersections (PSI). - + + + + + + + - **Robust and verifiable timestamps**: Messages timestamp is a way to show that the message existed prior to some point in time. However, the lack of timestamp verifiability can create room for a range of attacks, including injecting messages with invalid timestamps pointing to the far future. diff --git a/waku/standards/core/waku2.md b/waku/standards/core/waku2.md index c3d50ad..c9a5aba 100644 --- a/waku/standards/core/waku2.md +++ b/waku/standards/core/waku2.md @@ -352,10 +352,14 @@ therefore the service obtained in the protocol is linkable to the beneficiary's For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics. Likewise, in the `12/WAKU2-FILTER`, a full node can link the light node's `PeerID`s to its content filter. + + + + ## Appendix C: Implementation Notes ### Implementation Matrix