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

RLN: Update identity_secret generation #81

Closed
rymnc opened this issue Dec 6, 2022 · 6 comments · Fixed by #85
Closed

RLN: Update identity_secret generation #81

rymnc opened this issue Dec 6, 2022 · 6 comments · Fixed by #85
Assignees
Labels
track:rln RLN Track - (Secure Messaging/Applied ZK), relay and applications track:zerokit Zerokit track (Applied ZK/Explorations)

Comments

@rymnc
Copy link
Contributor

rymnc commented Dec 6, 2022

To make the credentials generated by RLN more compatible with Semaphore, we need to update the secret generation to include generation of the identity_trapdoor and identity_nullifier as mentioned in Semaphore's docs - https://semaphore.appliedzkp.org/docs/technical-reference/circuits

This will allow re-using the same credentials for Semaphore groups and RLN

cc: @s1fr0 @oskarth

@rymnc
Copy link
Contributor Author

rymnc commented Dec 6, 2022

cc: @AtHeartEngineer from the PSE team

@s1fr0
Copy link
Contributor

s1fr0 commented Dec 6, 2022

Thanks for the issue. I think was fairly agreed that we want to generate credentials as described in semaphore so that we have compatibility.

The only thing I'd like to know is if we want to keep current keygen implementation (that computes id_secret = random, id_commitment = H(id_secret)) and thus add a new keygen that computes credentials like semaphore, or we want to replace keygen implementation.

Given that changing current keygen implementation implies a refactor of zerokit, nwaku, go-waku, rln-wasm, etc. we could probably add a new API to allow smooth transition and then, in case, deprecate the old keygen.

@rymnc
Copy link
Contributor Author

rymnc commented Dec 6, 2022

Agreed!

@AtHeartEngineer
Copy link

@cedoor FYI

@oskarth
Copy link
Contributor

oskarth commented Dec 7, 2022

This would require a spec change right? If so we should have an issue and discussion/decision in RFC repo

@rymnc
Copy link
Contributor Author

rymnc commented Dec 7, 2022

I don't think this requires a spec change. The previous implementation was not according to spec, and now it is :)

@s1fr0 s1fr0 added the track:zerokit Zerokit track (Applied ZK/Explorations) label Dec 9, 2022
@s1fr0 s1fr0 self-assigned this Dec 9, 2022
@s1fr0 s1fr0 added the track:rln RLN Track - (Secure Messaging/Applied ZK), relay and applications label Dec 9, 2022
@s1fr0 s1fr0 closed this as completed in #85 Dec 11, 2022
@s1fr0 s1fr0 moved this to Done in Vac Research Dec 11, 2022
@s1fr0 s1fr0 removed this from Vac Research Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
track:rln RLN Track - (Secure Messaging/Applied ZK), relay and applications track:zerokit Zerokit track (Applied ZK/Explorations)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants