Integrating Noise protocols in Waku2

[s1fr0]

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:

• Curve25519 for Diffie-Hellman exchanges;
• ChaChaPoly for symmetric authenticated encryption;
• SHA256 as hash function.

This ultimately results in implementations for the following Noise protocols:

• Noise_K1K1_25519_ChaChaPoly_SHA256;
• Noise_XK1_25519_ChaChaPoly_SHA256;
• Noise_XX_25519_ChaChaPoly_SHA256;
• Noise_XXpsk0_25519_ChaChaPoly_SHA256,

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:

• XXpsk0 can be transformed to an XX handshake using an empty psk, thus can be tested with minor modification adapting nim-libp2p's XX implementation;
• XX can be transformed to an XK1 handshake if Bob doesn't transmit to Alice his static key, thus can be tested with minor modification adapting nim-libp2p's XX implementation;
• XK1can be transformed to K1K1 if Alice doesn't transmit to Bob her static key, thus can be tested with minor modification using XK1 implementation;

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

Context

Specifications:

• The Noise Protocol Framework
• 26/WAKU2-PAYLOAD
• noise-libp2p

Implementations:

• nim-libp2p noise implementation
• BLAKE2 nimcrypto implementation

Acceptance Criteria

• Adapt and integrate nim-libp2p's Noise processing rules and XX handshake implementations;
• Implement the XXpsk0 handshake;
• Implement the XK1 handhshake;
• Implement the K1K1 handhshake;
• (Optional) Add support to BLAKE2b and BLAKE2s hash functions.
• (Optional) Add support to Curve448 for elliptic curve Diffie-Hellman exchanges.

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

[jm-clius]

@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]

I agree. Thanks @jm-clius !