Signature and Encryption in Waku v2

1

Continuing the discussion from WakuMessage is missing waku pubkey and signature · Issue #179 · waku-org/js-waku · GitHub I have some questions/observations:

1. Introduction is Waku v1 specific

Looking at 7/WAKU-DATA specs

This specification describes the encryption, decryption and signing of the content in the data field used in Waku.

This points to Waku v1 only. My understanding is that it should be corrected to the following:

This specification describes the encryption, decryption and signing of the content in the data field used in Waku v1 and payload field in Waku v2 Message if version = 1.

2. Exclusive use of waku envelope terminology

The data field is used within the waku envelope, the field MUST contain the encrypted payload of the envelope.

waku envelope is not a term used in Waku v2, it would be good to propose an alternative wording matching Waku v2 terminology.

3. Fields to be encrypted not clear in ABNF

The data field is defined as follows:

data        = flags auxiliary-field payload padding [signature] [salt]

However, above it is stated that:

The fields that are concatenated and encrypted as part of the data field are:

  • flags
  • auxiliary field
  • payload
  • padding
  • signature

Which means that actually

clear = flags auxiliary-field payload padding

cipher is the encrypted result of clear.

data = cipher [signature] [salt]

Is that correct?

The current ABNF notation isn’t clear in respect of what data is encrypted.

4. Clarify what data is hashed for 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.

Is data the payload field by itself? Or flags auxiliary-field payload padding ?

5. Length of salt

; 2 bytes, if present (in case of symmetric encryption).
salt            = 2OCTET

Looking at the Waku v1 spec, it specifies the use of AES-GCM with 96 bits nonce/salt. So I assume there is a double typo here and it should be:

; 12 bytes, if present (in case of symmetric encryption).
salt            = 12OCTET

6. Allowed symmetric encryption schemes

By limiting the salt to 12 Bytes then we have a technical restriction in using AES-GCM. Why not specifying directly that if symmetric encryption is preferred then AES-GCM should be used?

7. Allowed asymmetric encryption schemes

To proceed with ECIES Encryption, the iv, mac and ephemeral key needs to be provided alongside the encrypted data to allow the recipient to decrypt the data.
The current format does not cater for these fields, meaning that only AES-GCM symmetric encryption is actually supported. Am I correct?

1 Like
2

As discussed at the last meeting, the action plan is:

  1. Have a new specs that re-contextualize waku envelope for Waku v2.
  2. Explicitly state some of the restrictions (e.g. AES-GCM with 12 Bytes IV only).
  3. Clarify some of the points so that it can be implement in js-waku from the spec.
  4. Take it from there, attempt implementation in js-waku and then extend the design (e.g. asymmetric encryption) when needed.