Continuing the discussion from WakuMessage is missing waku pubkey and signature · Issue #179 · status-im/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
datafield 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
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:
- auxiliary field
Which means that actually
clear = flags auxiliary-field payload padding
cipher is the encrypted result of
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.
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?