waku-org
/
specs
mirror of https://github.com/waku-org/specs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update noise.md

This commit is contained in:
Jimmy Debe 2024-02-14 18:20:50 -05:00 committed by GitHub
parent a89021a7f1
commit 9ff5286ead
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
standards/application/noise.md
View File

@ -6,12 +6,12 @@ editor: Giuseppe <giuseppe@status.im>
contributors:
---
This specification describes how payloads of [Waku messages](spec/14/) with [version 2](/spec/14/#version2) can be encrypted
This specification describes how payloads of [Waku messages](https://rfc.vac.dev/spec/14/) with [version 2](https://rfc.vac.dev/spec/14/#version2) can be encrypted
in order to achieve confidentiality, authenticity, and integrity
as well as some form of identity-hiding on communicating parties.
This specification extends the functionalities provided by [26/WAKU-PAYLOAD](/spec/26),
This specification extends the functionalities provided by [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/),
adding support to modern symmetric encryption primitives
and asymmetric key-exchange protocols.
@ -63,7 +63,7 @@ We note that all [design requirements](#Design-requirements) on exchanged messag
corresponding to a total of 1 Round Trip Time communication *(1-RTT)*.
In particular, identity-hiding properties can be guaranteed only if the recommendation described in [After-handshake](#After-handshake) are implemented.
In the following, we assume that communicating parties reciprocally know an initial [`contentTopic`](/spec/14/#wakumessage)
In the following, we assume that communicating parties reciprocally know an initial [`contentTopic`](https://rfc.vac.dev/spec/14/#wakumessage)
where they can send/receive the first handshake message(s).
We further assume that messages sent over a certain `contentTopic` can be efficiently identified by their intended recipients
thanks to an arbitrary 16 bytes long `message-nametag` field embedded in the message payload
@ -85,7 +85,7 @@ The symmetric primitives supported are:
## Specification
When [14/WAKU-MESSAGE version](/spec/14/#payload-encryption) is set to 2,
When [14/WAKU-MESSAGE version](https://rfc.vac.dev/spec/14/#payload-encryption) is set to 2,
the corresponding `WakuMessage`'s `payload` will encapsulate the two fields `handshake-message` and `transport-message`.
The `handshake-message` field MAY contain
@ -228,24 +228,24 @@ by hashing the result of an ephemeral-ephemeral Diffie-Hellman exchange every 1-
## Backward Support for Symmetric/Asymmetric Encryption
It is possible to have backward compatibility to symmetric/asymmetric encryption primitives from [26/WAKU-PAYLOAD](/spec/26),
effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](/spec/14/#version1) in [version 2](/spec/14/#version2).
It is possible to have backward compatibility to symmetric/asymmetric encryption primitives from [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/),
effectively encapsulating payload encryption [14/WAKU-MESSAGE version 1](https://rfc.vac.dev/spec/14/#version1) in [version 2](https://rfc.vac.dev/spec/14/#version2).
It suffices to extend the list of supported `protocol-id` to:
- `254`: AES-256-GCM symmetric encryption;
- `255`: ECIES asymmetric encryption.
and set the `transport-message` field to the [26/WAKU-PAYLOAD](/spec/26) `data` field, whenever these `protocol-id` values are set.
and set the `transport-message` field to the [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26) `data` field, whenever these `protocol-id` values are set.
Namely, if `protocol-id = 254, 255` then:
- `message-nametag`: is empty;
- `handshake-message-len`: is set to `0`;
- `handshake-message`: is empty;
- `transport-message`: contains the [26/WAKU-PAYLOAD](/spec/26) `data` field (AES-256-GCM or ECIES, depending on `protocol-id`);
- `transport-message`: contains the [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/) `data` field (AES-256-GCM or ECIES, depending on `protocol-id`);
- `transport-message-len` is set accordingly to `transport-message` length;
When a `transport-message` corresponding to `protocol-id = 254, 255` is retrieved,
it SHOULD be decoded as the `data` field in [26/WAKU-PAYLOAD](/spec/26) specification.
it SHOULD be decoded as the `data` field in [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26/) specification.
## Appendix: Supported Handshakes Description
@ -331,9 +331,9 @@ The main difference with `XX` is that Alice's and Bob's static keys, when transm
## References
1. [5/SECURE-TRANSPORT](https://specs.status.im/spec/5)
2. [10/WAKU2](/spec/10)
3. [26/WAKU-PAYLOAD](/spec/26)
4. [14/WAKU-MESSAGE](/spec/14/#version1)
2. [10/WAKU2](https://rfc.vac.dev/spec/10)
3. [26/WAKU-PAYLOAD](https://rfc.vac.dev/spec/26)
4. [14/WAKU-MESSAGE](https://rfc.vac.dev/spec/14/#version1)
5. [Noise protocol](http://www.noiseprotocol.org/noise.html)
6. [Noise handshakes as key-exchange mechanism for Waku2](https://forum.vac.dev/t/noise-handshakes-as-key-exchange-mechanism-for-waku2/130)
7. [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234)