-
Notifications
You must be signed in to change notification settings - Fork 15
Provide optional encryption & signing scheme for Waku v2 or not? #181
Comments
This issue might (or might not) be depended on #182 |
@cammellos @iurimatias speaking for Core/Desktop and Stimbus:
Also curious to hear @pedrouid and @bgits POV as consumers of Waku v2 that'd be separate from the Status protocol. What expectations do you have here? |
With regards to core, we would favor an option that maintains the current protocol properties, at least with regard to metadata protection and encryption. This has not to be the same exactly, but if we want to maintain compatibility then that needs to be taken into consideration. Having waku-2 provide only a signature scheme is not of much use to us, as we have our own signature scheme that suits our use case better, though it might still be worth providing for other use cases. Removing completely encryption/signature scheme means that probably a non trivial amount of work needs to be done to provide something similar to our users, so that's the least favorite and if that's the direction we are going a discussion needs to be had about who will be working on this piece of work. |
I might be lacking a lot of context here, but as I understood Whisper the main benefit was the encryption layer which provided metadata protection. My assumption had been that Waku would do this as well. Now I'm curious what a Waku without this feature would be, and how is it different from simply Gossipsub in libp2p? |
Hi @oed! Waku v2 is a WIP so some things are still in flux, like the issue here :) You can see some of its design goals in the main spec here: https://specs.vac.dev/specs/waku/v2/waku-v2.html From the point of view of Waku, the use of GossipSub is an implementation detail. You are correct in the sense that one of the protocols, the relay protocol, is currently shadowing GossipSub. The goal is to extend this in the future. E.g. we don't want signing, we might use topics and do validation a bit separately, etc etc. Here's a PR for addressing the issue above in a more iterative manner #199 that might answer some questions. There is more work to be done here (e.g. better packet format). Whisper/Waku v1 and metadata protection is a big topic, and something we are studying in more detail (we just hired a privacy researcher this week). It received some of its benefits from payload encryption, but that's just part of the story (the other is flooding/routing and trade off with bw/scaling). The design was complecting routing and encryption a bit, and one of the goals of Waku v2 is to simplify the protocol and structure things slightly better. Hope that paints a bit of a better picture of how we are thinking about this. If you have more questions or want to talk about it more, feel free to join us in #vacp2p or #waku on Telegram/Discord/Status! |
Additionally, don't confuse metadata protection of the application layer and of the transport/routing layer. With Waku/Whisper you are trying to have a privacy focused transport layer, in order to avoid any linkability from a message on the network to any peer on that network. This is different from making sure that the message payload is encrypted so that no unintended user can read it and possibly link it to another user (=application). Of course, it does not mean that we can leave everything unencrypted. We likely need to encrypt anyhow, e.g. in case we need to add certain routing information (which is not really the case for e.g. Whisper/Waku v1 and I guess FloodSub to that extent). Perhaps there are also scenario's where you don't need encryption at all? As long as the message cannot be linked. |
Addressed in #199 |
Problem
This issue is there to decide on whether we should still have optional encryption and signing of message payload inside Waku v2 specs or not. And if so, whether it should look like the current one in Waku v1.
Acceptance criteria
Decide on what to support in Waku v2.
Details
It has initially been proposed to no longer support the optional encryption, from Waku v1, in Waku v2.
This would basically mean no longer specifying the envelope data format in waku v2: https://github.com/vacp2p/specs/blob/master/specs/waku/v1/envelope-data-format.md
Currently this optional specification specifies encryption through asymmetric keys or symmetric keys. It however specifies nothing regarding key agreement (this is considered out of band).
The idea was there to remove this from Waku:
However, the latter is only partially true. Within Status It is still used for Public chats and Double rachet has the header in clear text because there is already this encryption on top ( see waku-org/nwaku#39 (comment)).
The Status chat is also dependend on the signing of the messages, to identify the pseudo-anonymous handle.
It should also be noted that changing this between Waku v1 & v2, or just between Waku versions in general, will require nodes (clients) to support both formats as long as messages are being bridged between these versions. This is because the bridge itself cannot convert as it cannot decrypt and/or resign messages.
Possible Solutions
Now we have some options:
while, until bridging between versions is dropped. However, this could be done
independently of waku v2, and e.g. already be done in Waku v1, as it is optional
after all (but still might require Waku API changes I'm guessing).
Notes
I believe this or the goal of this is not unimportant within Waku and requires additional research.
A new ticket will be created for this.
The text was updated successfully, but these errors were encountered: