Reduce chances of loosing RLN credentials.

[fryorcraken]

Problem

Credentials are purely generated from entropy, meaning that if a user lose access to their key, then they lose access to their RLN membership.

Proposed Solution

A. Seed derivation from signature

1. Make user sign message M: The signature of this message will be used to generate your RLN credentials. Ensure that this signature is only shared with the RLN dApp.
2. Hash signature
3. Use hash as seed for RLN credentials generation

As long as the user has access to their Ethereum private key, they can regenerate their credentials.

They also need to be able to retrieve their membership id.

To do so:

1. Look at past transactions sent from this wallet
2. Find transaction sent to RLN contract
3. Check receipt to get the membership id

B. Secure storage of credentials in cryptkey-like extension

Another strategy is to store the credentials in an extensions.

Acceptance Criteria

• Implement A

Note

Zerokit now supports seeded keygen: vacp2p/zerokit#56

Strategy B can be done at a later stage.

[fryorcraken]

@staheri14 @s1fr0 please clarify:

1. What hash should be used to hash the signature before feeding it to zerokit as a seed?
2. What message would you prefer we use?
3. Most ZK projects I have see use eth personal sign. Do we want to also use it? Should we try to use EIP-712 instead? It might have better security if the wallet checks the name in the data struct to sign against the domain name of the app
4. Discussion about a password and nonce were made, do we want to implement either? Feel free to forward me to an RFC if I missed it.
5. I assume that the membership id is present in the event logs of the registration transaction, am I correct? @richard-ramos ?

[richard-ramos]

I assume that the membership id is present in the event logs of the registration transaction, am I correct? @richard-ramos ?

Yes, it's the index parameter of the event MemberRegistered(uint256 pubkey, uint256 index)

[staheri14]

@fryorcraken for 2 and 4, the contract address and the nonce are definitive. With nonce we allow multiple registrations to the same membership contract. However, for the password, we yet did not get to an agreement. To me still it makes sense to have an app-level password to make sure the same seed (hence rln credentials) will not be derived by a malicious irrelevant application.

[s1fr0]

1. Given that entropy comes from a signature (high-entropy) rather than a password (low entropy) I would derive the secret using HKDF with SHA256. Note that HKDF can take not only the raw signature as input, but also an optional salt and info input data (which are hashed all together). This feature can be particularly useful to mitigate rainbow table attacks (unlikely here since we don't use passwords) and to pass the nonce to the key derivation function rather than to the signing routine. Since we don't want to store salt, we could just set it to some value derived again from signature.

2. I think "Sign this message to derive credentials for app X deployed on contract X with chain-id X" would be enough. To generate multiple credentials, we can pass the nonce (actually better to call it counter, otherwise we should think how to persist a random nonce) to the key derivation function (see 1.). I don't agree with the usage of a password: this credential derivation method employing wallet signatures is done in order to avoid remembering/storing additional credentials beside the wallet auth data. Furthermore if require a password we can derive credentials directly from that with no need for wallet signature. Note however that what I described in 1. still allows you to pass arbitrary data to the key derivation function, including any eventual app-level info/password. If you think is necessary to discuss it further, @staheri14 please open an issue where we can discuss security assumptions for a password approach in a more structured way.

3. Had just a glance to EIP-712 full specification, but yes Sign Typed Data v3/v4 is what I was looking at. Plus chain-id is already there along with other meaningful fields (domain/name) and there is an open message field. I think this format enormously mitigates any potential replay/impersonation attack.

4. See 2.

5. Yes!

[fryorcraken]

Note that it may be more efficient (less network request) to look at the merkle tree to recover the membership id. See waku-org/nwaku#1278 (comment)