Open richard-ramos opened 1 year ago
@richard-ramos can we have more details please? :)
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).
cool, do have tests for those?
The hardcoding seems fine because the RFC does not allow alternative hash or encryption scheme AFAIK
@richard-ramos does the new description seem accurate?
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.