Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved encrypted Waku Payload #59

Open
jimstir opened this issue Jun 13, 2024 · 0 comments
Open

Improved encrypted Waku Payload #59

jimstir opened this issue Jun 13, 2024 · 0 comments

Comments

@jimstir
Copy link
Collaborator

jimstir commented Jun 13, 2024

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant