Reduce chances of loosing RLN credentials. about js-rln HOT 5 CLOSED

@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 ?

from js-rln.

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)

from js-rln.

@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.

from js-rln.

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!

from js-rln.

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)

from js-rln.