vacp2p
/
rfc
mirror of https://github.com/vacp2p/rfc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

spec/fix-rpl-abnf (#52) 

* fixes

* indent

* rearranged

* Update waku.md

* commit
This commit is contained in:
Dean Eigenmann 2019-12-05 05:13:25 +01:00 committed by Oskar Thorén
parent 4b2a6c6841
commit 70e8c06730
1 changed files with 44 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
waku.md
View File

@ -75,57 +75,61 @@ Waku is a RLPx subprotocol called `waku` with version `0`. The version number co
Using [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234) we have the following format:
```
bytes = [repeat] OCTET
; Packet codes 0 - 127 are reserved for Waku protocol
packet-code = 0 / 1 / 2 / 3 / [ x4-127 ]
packet-code = 1*3DIGIT
packet-format = "[" packet-code packet-format "]"
; packet-format needs to be paired with its corresponding packet-format
packet = "[" required-packet / [ optional-packet ] "]"
required-packet = 0 status / 1 messages / 2 pow-requirement / 3 bloom-filter
optional-packet = 126 p2p-request / 127 p2p-message
packet-format = "[" packet-code packet-format "]"
status = "[" version pow-requirement [ bloom-filter ] [ light-node ] "]"
status = "[" version pow-requirement [ bloom-filter ] [ light-node ] "]"
; version is "an integer (as specified in RLP)"
version = DIGIT
version = DIGIT
messages = *waku-envelope
; pow is "a single floating point value of PoW. This value is the IEEE 754 binary representation of 64-bit floating point number. Values of qNAN, sNAN, INF and -INF are not allowed. Negative values are also not allowed."
pow-requirement = pow
; pow is "a single floating point value of PoW.
; This value is the IEEE 754 binary representation
; of a 64-bit floating point number.
; Values of qNAN, sNAN, INF and -INF are not allowed.
; Negative values are also not allowed."
pow-requirement = pow
; bloom filter is "a byte array"
bloom-filter = bytes
bloom-filter = *OCTET
light-node = BIT
light-node = BIT
p2p-request = waku-envelope
p2p-message = waku-envelope
whisper-envelope = "[" expiry ttl topic data nonce "]"
waku-envelope = "[" expiry ttl topic data nonce "]"
; 4 bytes (UNIX time in seconds)
expiry = bytes
expiry = 4OCTET
; 4 bytes (time-to-live in seconds)
ttl = bytes
ttl = 4OCTET
; 4 bytes of arbitrary data
topic = bytes
topic = 4OCTET
; byte array of arbitrary size (contains encrypted message)
data = bytes
; byte array of arbitrary size
; (contains encrypted message)
data = OCTET
; 8 bytes of arbitrary data (used for PoW calculation)
nonce = bytes
; 8 bytes of arbitrary data
; (used for PoW calculation)
nonce = 8OCTET
messages = 1*waku-envelope
p2p-request = waku-envelope
p2p-message = 1*waku-envelope
packet-format = "[" packet-code packet-format "]"
required-packet = 0 status / 1 messages / 2 pow-requirement / 3 bloom-filter
optional-packet = 126 p2p-request / 127 p2p-message
; packet-format needs to be paired with its corresponding packet-format
packet = "[" required-packet [ optional-packet ] "]"
packet-format = "[" packet-code packet-format "]"
```
All primitive types are RLP encoded. Note that, per RLP specification, integers are encoded starting from `0x00`.
@ -233,8 +237,9 @@ The Data field contains the encrypted message of the envelope. In case of symmet
Using [Augmented Backus-Naur form (ABNF)](https://tools.ietf.org/html/rfc5234) we have the following format:
```
; 1 byte; first two bits contain the size of auxiliary field, third bit indicates whether the signature is present.
flags = 1*OCTET
; 1 byte; first two bits contain the size of auxiliary field,
; third bit indicates whether the signature is present.
flags = 1OCTET
; contains the size of payload.
auxiliary-field = 4*OCTET
@ -246,12 +251,12 @@ payload = *OCTET
padding = *OCTET
; 65 bytes, if present.
signature = 65*OCTET
signature = *65OCTET
; 2 bytes, if present (in case of symmetric encryption).
salt = 2*OCTET
salt = 2OCTET
envelope = flags auxiliary-field payload padding [signature] salt
envelope = flags auxiliary-field payload padding [signature] [salt]
```
Those unable to decrypt the message data are also unable to access the signature. The signature, if provided, is the ECDSA signature of the Keccak-256 hash of the unencrypted data using the secret key of the originator identity. The signature is serialised as the concatenation of the `R`, `S` and `V` parameters of the SECP-256k1 ECDSA signature, in that order. `R` and `S` are both big-endian encoded, fixed-width 256-bit unsigned. `V` is an 8-bit big-endian encoded, non-normalised and should be either 27 or 28.