Skip to content
This repository has been archived by the owner on Jun 14, 2024. It is now read-only.

17/WAKU-RLN-RELAY: File format to backup credentials? #543

Closed
3 tasks
Tracked by #1466 ...
fryorcraken opened this issue Oct 5, 2022 · 4 comments
Closed
3 tasks
Tracked by #1466 ...

17/WAKU-RLN-RELAY: File format to backup credentials? #543

fryorcraken opened this issue Oct 5, 2022 · 4 comments
Labels
track:rlnp2p RLNP2P Track (Secure Messaging), applications of rln in p2p context

Comments

@fryorcraken
Copy link
Contributor

Problem

RLN credentials are composed of 3 elements:

  • identity key (secret)
  • membership index/id
  • identity commitment

We currently manipulate these information in string format:

  • identity key: hex string (no 0x prefix)
  • membership index/id: decimal
  • identity commitment: hex string (no 0x prefix)

This is not ideal as one needs to copy/backup 3 piece information when porting their credentials from one node to another (e.g. nwaku's chat2 to js-waku example rln-js).

Acceptance criteria

  • Define a common file format to backup RLN credentials that can be imported/exported by various implementations
  • Define an encryption method to keep the format safe
  • Bonus: specify a single string format (ie, JSON) to easily copy/paste credentials in one go.

Details

Possible Solutions

Notes

@fryorcraken fryorcraken added the track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications label Oct 5, 2022
@staheri14 staheri14 moved this to New in Vac Research Oct 14, 2022
@staheri14 staheri14 moved this from New to Later/Icebox in Vac Research Oct 14, 2022
@s1fr0
Copy link
Contributor

s1fr0 commented Oct 14, 2022

Related issue: waku-org/nwaku#1238

@s1fr0
Copy link
Contributor

s1fr0 commented Oct 17, 2022

When you talk about export/import you mean in encrypted form? Most likely we will use JSON to store credentials and all the crypto information (salt, hashes, etc.) and such JSON will always remain on disk in encrypted form (it's decrypted on the fly when creating proofs after submitting the password).

This means that you cannot directly copy/paste this json to another implementation if you don't implement first the same crypto primitives. For this reason I was thinking if it's worth to implement a "credentials" module in rust rather than only in nim, that we can (hopefully) target to both C/WASM.

However, I'm not sure this effort makes sense if we want to use a browser extension like https://github.com/Rate-Limiting-Nullifier/crypt-keeper to store credentials (that we might generate from a deterministic wallet signature).
go-waku supports already ChaChaPoly (that I want to use for encryption + Argon2), so having nim/go separate implementations might still be doable. But to target js/go/nim all at the same time, probably rust would work better.

@oskarth

@s1fr0
Copy link
Contributor

s1fr0 commented Oct 25, 2022

Note that in any proposed solution the RLN index should have a fixed size (e.g. in hex of either 4 or 8 bytes). The reason is that credentials will be encypted using the Web3 Secure standard which uses aes-ctr with ciphertext having same size as plaintext. If the RLN index is kept as decimal (more precisely the byte representation of the string expressing the index in decimal) then, for example, the index 99 might be distinguished from 100 by observing the extra byte.

@rymnc rymnc added track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications track:rlnp2p RLNP2P Track (Secure Messaging), applications of rln in p2p context and removed track:rln RLN Track (Secure Messaging/Applied ZK), e.g. relay and applications labels Jan 19, 2023
@s1fr0 s1fr0 mentioned this issue Feb 8, 2023
3 tasks
@s1fr0
Copy link
Contributor

s1fr0 commented Feb 8, 2023

This issue has been addressed by waku-org/nwaku#1285 and its follow-up PR waku-org/nwaku#1466. The solution implements waku-org/nwaku#1238 (comment), that is a structured JSON keystore supporting multiple membership credentials encrypted with an implementation derived from nimbus keyfile module.

However the above PRs do not address the update of the 17/WAKU-RLN-RELAY RFC as per the title of this issue. Such update is tracked in #571, where a new RFC detailing the new waku_keystore module is requested. As a result this issue can be closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
track:rlnp2p RLNP2P Track (Secure Messaging), applications of rln in p2p context
Projects
Status: Done
Development

No branches or pull requests

3 participants