Improved encrypted Waku Payload

[jimstir]

Reference issue: vacp2p/rfc#414
Author: oskarth
This is a list of possible weaknesses, unknowns and enhancements of vacp2p/rfc#413

The goal is to collect requirements and identify potential issues in the existing behavior.

List of things to investigate

1. Issue with v parameter

This should be 0,1, but due to Bitcoin standard it is 27, 28. Later on, this has moved in Ethereum to:

V = CHAIN_ID * 2 + 35:

See:

• https://eips.ethereum.org/EIPS/eip-155
• Inconsistent usage of V values in signatures ethereum/go-ethereum#19751 (comment)
• https://coders-errand.com/ecrecover-signature-verification-ethereum/

2. Does RLPx / Devp2p known crypto issue impacts us?

See https://github.com/ethereum/devp2p/blob/master/rlpx.md#ecies-encryption and https://crypto.stackexchange.com/questions/63047/ethereum-rlpx-protocol-for-inter-node-communication-flaws-in-the-encryption

It seems mostly to deal with handshake etc, but there is some stuff around how MAC works that I'm not 100% sure about.

3. More rigorous unlinkability

Not clear to me how strong unlinkability guarantees we can make here, also see vacp2p/rfc#182

4. Generally use better primitives

For example, see this https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html

Noise protocol https://noiseprotocol.org/noise.html

djb on The security impact of a new cryptographic library https://cr.yp.to/highspeed/coolnacl-20111201.pdf

libsodium https://doc.libsodium.org/

Eg Curve25519, XSalsa20+Poly1305, scrypt

We'd have to be mindful of things like downgrade attacks here (see TLS 1.2 vs 1.3) so backwards compatibility would be an issue.

5. Provide for forward secrecy (probably separate spec)

Right now this is a separate spec, which probably makes sense, but it'd be good if this was a building block that is easy to integrate.

A good first step would be to move that spec to rfc.vac.dev and adapt it to make it a bit more general.

Also some ideas for other ways of doing forward secrecy, e.g. Noise, punctured encryption.

6. Provide for group key exchange (probably separate spec)

Currently 1-1 is used in Status chat, some work on Megolm is starting for Status communities. There has been talk about decentralized MLS as well. This is a whole research area but mentioning it here for completeness.