From cc84edca9c18d5cacc64b096e5a702dafdae5cc3 Mon Sep 17 00:00:00 2001 From: Franck Royer Date: Thu, 26 Aug 2021 16:27:17 +1000 Subject: [PATCH] Rephrase, typos --- guides/encrypt-messages-version-1.md | 35 ++++++++++++++-------------- 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/guides/encrypt-messages-version-1.md b/guides/encrypt-messages-version-1.md index 8c7863fb81..1587261ad2 100644 --- a/guides/encrypt-messages-version-1.md +++ b/guides/encrypt-messages-version-1.md @@ -8,19 +8,19 @@ You can find more details about Waku Message Payload Encryption in [26/WAKU-PAYL ## What data is encrypted -With waku Message version 1, the payload is encrypted. +With Waku Message Version 1, the entire payload is encrypted. Which means that the only discriminating data available in clear text is the content topic and timestamp (if present). -Hence, if Alice expects to receive messages under a given content topic, she needs to try decrypting of all messages received on said content topic. +Hence, if Alice expects to receive messages under a given content topic, she needs to try to decrypt all messages received on said content topic. This needs to be kept in mind for scalability and forward secrecy concerns: -- If there is high traffic on a given content topic then all clients need to process said traffic; -- If a content topic is only used by a give (group of) users then it is possible to deduce some information about their communication such time and frequency of messages. +- If there is high traffic on a given content topic then all clients need to process and attempt decryption of all messages with said content topic; +- If a content topic is only used by a given (group of) user(s) then it is possible to deduce some information about said user(s) communications such as sent time and frequency of messages. ## Key management -By using Waku Message Version 1, you will need to provide a way for your user to generate and store keys in a secure manner. +By using Waku Message Version 1, you will need to provide a way to your users to generate and store keys in a secure manner. Storing, backing up and recovering key is out of the scope of this guide. @@ -31,12 +31,12 @@ Whether you should use symmetric or asymmetric encryption depends on your use ca **Symmetric** encryption is done using a single key to encrypt and decrypt. -Which means that if Alice knows `K` and use it to encrypt a message, +Which means that if Alice knows the symmetric key `K` and uses it to encrypt a message, she can also use `K` to decrypt any message encrypted with `K`, even if she is not the sender. Group chats is a possible use case for symmetric encryption: -All participants can use an out-of-band method to determine `K`. +All participants can use an out-of-band method to agree on a `K`. Participants can then use `K` to encrypt and decrypt messages within the group chat. Participants MUST keep `K` secret to ensure that no external party can decrypt the group chat messages. @@ -48,7 +48,7 @@ For Alice to encrypt a message for Bob, she needs to know Bob's Public Key `K`. Bob can then use his private key `k` to decrypt the message. As long as Bob keep his private key `k` secret, then he, and only he, can decrypt messages encrypted with `K`. -Private messaging is a possible use case for aasymmetric encryption: +Private 1:1 messaging is a possible use case for asymmetric encryption: When Alice sends an encrypted message for Bob, only Bob can decrypt it. ## Symmetric Encryption @@ -77,7 +77,7 @@ See [Receive and Send Messages Using Waku Relay](relay-receive-send-messages.md) import { WakuMessage } from 'js-waku'; const message = await WakuMessage.fromBytes(payload, contentTopic, { - symKey: key, + symKey: key }); ``` @@ -118,12 +118,12 @@ Symmetric keys or asymmetric private keys can be mixed, both decryption methods ```js // Using await syntax -const messages = await waku2.store.queryHistory([contentTopic], { +const messages = await waku.store.queryHistory([contentTopic], { decryptionKeys: [key] }); // Using callback syntax -waku2.store.queryHistory([contentTopic], { +waku.store.queryHistory([contentTopic], { decryptionKeys: [key], callback: (messages) => { // Process decrypted messages @@ -155,8 +155,8 @@ hence it is not needed to save it as long as as the private key can be recovered ### Encrypt Message -The public key is used to encrypt messages, to do so, -pass the key in the `encPublicKey` property to `WakuMessage.fromBytes`. +The public key is used to encrypt messages; +to do so, pass it in the `encPublicKey` property to `WakuMessage.fromBytes`. Same as clear Waku Messages, `payload` is your message payload and `contentTopic` is the content topic for your dApp. @@ -240,13 +240,12 @@ const message = await WakuMessage.fromBytes(payload, contentTopic, { console.log(message.payload); // This is encrypted ``` -However, `WakuMessage` instances returned by `WakuRelay` or `WakuStore` are decrypted, -if the correct decryption key is passed as explained previously. +However, `WakuMessage` instances returned by `WakuRelay` or `WakuStore` are always decrypted. -`WakuRelay` and `WakuStore` never returned messages that are encrypted. -If a message was not succesfully decrypted, then it will be dropped from the results. +`WakuRelay` and `WakuStore` never return messages that are encrypted. +If a message was not successfully decrypted, then it will be dropped from the results. -Which means that `WakuMessage` instances returned by `WakuRelay` and `WkauStore` always a clear payload (in regard to Waku Message version 1): +Which means that `WakuMessage` instances returned by `WakuRelay` and `WakuStore` always have a clear payload (in regard to Waku Message version 1): ```js const messages = await waku.store.queryHistory([contentTopic], {