Provide optional encryption & signing scheme for Waku v2 or not?

[kdeme]

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:

• to simplify the API by no longer requiring the separate key management part and additional encryption within Waku, but rather have this in the application (per application). The latter is actually already possible, as the spec does not demand it. However, I'm unsure if all implementations allow unencrypted and unsigned payloads (for sure the RPC calls don't).
• and additionally, because the encryption step on the payload, as defined by Waku v1, seemed obsolete. Status for example uses X3DH + Double Rachet on top (see also https://github.com/status-im/specs/blob/master/docs/stable/5-secure-transport.md#end-to-end-encryption) for reasons of key-agreement, PFS, established standards, etc.

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:

• Stick with the current format. Keep it optional, but allow some helper code in Waku v2 to still do this easily (however, keep the code as separate as possible from the core). Let the applications decide if, when and how they want to move away from this.
• Change the format in v2. Keep it optional, but change the format to whatever seems more reasonable today. E.g. drop encryption but keep the signature (not sure if that is OK actually).
  • This will require applications to support both formats for a while, until bridging between versions is dropped.
• Drop this completely from Waku. Let the application fully decide.
  • This will require applications to move this a "layer up".
  • If changes are made, applications will need to support both formats for a
    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

• There is also currently the padding in the definition of the envelope data format (see also Sketch out Waku v2 making API smaller, separate key crypto ops waku-org/nwaku#39 (comment)).
  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.

[kdeme]

This issue might (or might not) be depended on #182

[oskarth]

@cammellos @iurimatias speaking for Core/Desktop and Stimbus:

1. Do you have any preference for the options outlined above?
2. Do you see any other options?

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?

[cammellos]

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.

[oed]

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?

[oskarth]

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!

[kdeme]

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).
Or for example, when adding padding to have the messages all at a standard length.
But for the latter example you can however also just explicitly state that the payload must look like a random stream of data, and thus be encrypted, but with no obligation of how this should be done. This way you avoid having to encrypt twice, which is what we are discussing here.

Perhaps there are also scenario's where you don't need encryption at all? As long as the message cannot be linked.

[oskarth]

Addressed in #199