waku-org / js-noise

Browser library using Noise Protocols for Waku Payload Encryption https://rfc.vac.dev/spec/35/
Apache License 2.0
3 stars 2 forks source link

feat: create function for devs to customize patterns #3

Open richard-ramos opened 1 year ago

richard-ramos commented 1 year ago

Problem

All patterns from the 35/WAKU2-NOISE RFC are available https://github.com/waku-org/js-noise/blob/master/src/patterns.ts

However, the API has not been reviewed and there are no examples to demonstrate their usage.

Acceptance Criteria

For each handshake:

Priority: do it on a need basis

Check list:

Notes

The hashing, cipher and curve are currently hardcoded (SHA-256, ChaChaPoly and ed25519). This is as per the RFC so seems find to leave as is.

fryorcraken commented 1 year ago

@richard-ramos can we have more details please? :)

richard-ramos commented 1 year ago

We currently have these patterns available https://github.com/waku-org/js-noise/blob/master/src/patterns.ts with those specific protocolIDs

- Noise_K1K1_25519_ChaChaPoly_SHA256: 10,
- Noise_XK1_25519_ChaChaPoly_SHA256: 11,
- Noise_XX_25519_ChaChaPoly_SHA256: 12,
- Noise_XXpsk0_25519_ChaChaPoly_SHA256: 13,
- Noise_WakuPairing_25519_ChaChaPoly_SHA256: 14,

These are the handshake patterns defined in the RFC, but maybe we should refactor the code so it's easy for a developer to be able to create new patterns, and allow them to specify the hashing and cipher to be used instead of hardcoding the sha256 and chachapoly, as well as specifying the type of curve to be used (instead of only allowing 25519).

fryorcraken commented 1 year ago

cool, do have tests for those?

The hardcoding seems fine because the RFC does not allow alternative hash or encryption scheme AFAIK

fryorcraken commented 1 year ago

@richard-ramos does the new description seem accurate?