Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: create function for devs to customize patterns #3

Open
5 tasks
richard-ramos opened this issue Nov 15, 2022 · 4 comments
Open
5 tasks

feat: create function for devs to customize patterns #3

richard-ramos opened this issue Nov 15, 2022 · 4 comments
Labels
track:conversational-security Conversational security track (Secure Messaging)

Comments

@richard-ramos
Copy link
Member

richard-ramos commented Nov 15, 2022

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:

  • Review the API
  • Include a test
  • Provide a usage example
  • Provide some docs

Priority: do it on a need basis

Check list:

  • Noise_XK1_25519_ChaChaPoly_SHA256: Should be sorted with WebRTC for Waku js-waku#1181. Improve the API, ensure there is test coverage as it's being used.
  • Noise_WakuPairing_25519_ChaChaPoly_SHA256: Should already be covered by the library, to double check (API and coverage) once above is done so we are familiar with API
  • Noise_XX_25519_ChaChaPoly_SHA256
  • Noise_XXpsk0_25519_ChaChaPoly_SHA256
  • Noise_K1K1_25519_ChaChaPoly_SHA256

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.

@richard-ramos richard-ramos changed the title create function for devs to customize patterns feat: create function for devs to customize patterns Nov 15, 2022
@fryorcraken
Copy link
Contributor

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

@richard-ramos
Copy link
Member Author

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
Copy link
Contributor

fryorcraken commented Mar 30, 2023

cool, do have tests for those?

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

@fryorcraken
Copy link
Contributor

@richard-ramos does the new description seem accurate?

@fryorcraken fryorcraken added track:conversational-security Conversational security track (Secure Messaging) API documentation Improvements or additions to documentation and removed documentation Improvements or additions to documentation labels Mar 30, 2023
@fryorcraken fryorcraken removed the API label Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
track:conversational-security Conversational security track (Secure Messaging)
Projects
Status: To Do
Development

No branches or pull requests

2 participants