waku-org / nwaku

Waku node and protocol.
Other
187 stars 49 forks source link

Integrating Noise protocols in Waku2 #881

Open s1fr0 opened 2 years ago

s1fr0 commented 2 years ago

Problem

26/WAKU2-PAYLOAD defines how message payloads can be encrypted using symmetric/asymmetric primitives. However, a protocol to allow users to safely exchange encryption cryptographic keys is missing.

Issue vacp2p/rfc#494 and this Vac forum post propose to integrate multiple Noise handshakes in Waku2 to address the current lack of key-exchange protocols.

This issue addresses the third item of vacp2p/research#97 by setting a rough plan for the integration of the Noise handshakes K1K1, XK1, XX, XXpsk0 into nim-waku. Their description, the assumed security model and provided security properties can be found following the above references.

Future issues will address the required changes to support encoding/decoding of Waku2 message payloads encrypted according to implemented Noise protocols' encryption/decryption rules.

Underlying Cryptographic Primitives

We plan to instantiate the K1K1, XK1, XX, XXpsk0 handshakes using the following underlying cryptographic primitives:

This ultimately results in implementations for the following Noise protocols:

named according to Noise protocols naming conventions.

However, BLAKE2 family of hash functions is conjectured to offer better security guarantees (random oracle indifferentiable) and offers faster hashing times (a Nim implementation for BLAKE2 is provided in nimcrypto). Future PRs might integrate support for the BLAKE2 hash functions family (in particular, BLAKE2s) as underlying hash primitive.

Future PRs might integrate support for the Curve448 elliptic curve as well, in order to instantiate Diffie-Hellman exchanges on an higher bit-security level.

Handshake Implementation Timeline

We plan to adapt and integrate nim-libp2p's Noise_XX_25519_ChaChaPoly_SHA256 implementation in nim-waku.

We then propose to implement and integrate the remaining Noise handshakes in the following order:

  1. XXpsk0.
  2. XK1;
  3. K1K1;

This is motivated by the following facts:

We note, however, that the logic used to derive the shared key material slightly differ among such handshakes.

Context

Specifications:

Implementations:

Acceptance Criteria

@oskarth @staheri14 @jm-clius @kaiserd @D4nte @cammellos

jm-clius commented 2 years ago

@s1fr0 moving this from "In Progress", as I think the remaining work is optional and not actively worked on. Feel free to move back if needed.

s1fr0 commented 2 years ago

I agree. Thanks @jm-clius !