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

[fryorcraken]

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

[s1fr0]

Related issue: https://github.com/status-im/nwaku/issues/1238

[s1fr0]

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]

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.

[s1fr0]

This issue has been addressed by https://github.com/waku-org/nwaku/pull/1285 and its follow-up PR https://github.com/waku-org/nwaku/pull/1466. The solution implements https://github.com/waku-org/nwaku/issues/1238#issuecomment-1278114079, 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 https://github.com/vacp2p/rfc/issues/571, where a new RFC detailing the new waku_keystore module is requested. As a result this issue can be closed.