search

vacp2p / research

Thinking in code
MIT License
62 stars 4 forks source link

Secure device session transfers with Noise #134

Closed s1fr0 closed 1 year ago

s1fr0 commented 1 year ago

This PR addresses https://github.com/vacp2p/research/issues/130 by proposing and analyzing a pairing protocol for two devices using Waku, in order to ultimately be able to securely exchange cryptographic material.

This PR addresses https://github.com/status-im/nwaku/issues/1065.

FYI @Samyoul

s1fr0 commented 1 year ago

@staheri14 @fryorcraken @jm-clius could you please have a look to the design proposed in this PR? Thanks!

s1fr0 commented 1 year ago

@fryorcraken

Why do we need a message id in the content topic? I'd avoid it if possible.

It is thought for efficiency reasons, i.e. avoid many (failing) trial decryptions. See related discussion in https://github.com/status-im/nwaku/issues/1081. As proposed in the opening post it can be embedded in the Waku message payload field instead and leave the content topic to something like /{application-name}/{application-version}/wakunoise/1/sessions-{shard-id}/

fryorcraken commented 1 year ago

@fryorcraken

Why do we need a message id in the content topic? I'd avoid it if possible.

It is thought for efficiency reasons, i.e. avoid many (failing) trial decryptions. See related discussion in status-im/nwaku#1081. As proposed in the opening post it can be embedded in the Waku message payload field instead and leave the content topic to something like /{application-name}/{application-version}/wakunoise/1/sessions-{shard-id}/

Makes sense thanks.

Currently it is not easy/possible to use GLOB in content topics in most waku implementations.

We need to consider whether content topic GLOB is the best design moving forward or if we can find an alternative.

If the message id is deterministic, it might make sense to have it in the content topic. However, when using filter, Alice would have to successfully subscribe to a new content topic before Bob sends the next message which may not be ideal.

An id field in the clear part of the payload would make sense so that only message with an expected field are decrypted as you suggested.

How would you deterministically generate the message id? (or did I miss that in the doc?).

fryorcraken commented 1 year ago

Nothing to add for me :+1:. My concerns are already being addressed/discussed.

s1fr0 commented 1 year ago

This write-up become a RAW RFC proposal in https://github.com/vacp2p/rfc/pull/531 and will not be further updated here. Please report any further comment in https://github.com/vacp2p/rfc/pull/531 instead.