You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: