RLN: strengthen security of rln_identifier

[s1fr0]

Problem

In https://rfc.vac.dev/spec/32/ it is stated that

RLN Identifier: Random finite field value unique per RLN app. It is used for additional cross-application security. The role of the RLN identifier is protection of the user secrets being compromised if signals are being generated with the same credentials at different apps.

however x,y coordinates are independent from rln_identifier. In other words, if a user publishes for the same external nullifier and in two different RLN-based apps, the shares (x1,y1) and (x2,y2) (one per application) generated starting from the same identity_secret, then recovering the latter is still possible similarly as happens in the stashing mechanism. In fact we have

a_0 = identity_secret
a_1 = poseidonHash([a0, external_nullifier])

y = a_0 + x * a_1

internal_nullifier = poseidonHash([a_1, rln_identifier])

Possible solution

From multiple parts of the RFC it appears that external_nullifier can be the epoch, the timestamp or the hash of these values, hence might be the same among different applications.

I propose instead to change the parameters to something similar to

external_nullifier = poseidonHash([epoch, rln_identifier])
a_0 = identity_secret
a_1 = poseidonHash([a0, external_nullifier])

y = a_0 + x * a_1

internal_nullifier = poseidonHash([a_1, rln_identifier]) // or internal_nullifier = poseidonHash([a_1])

so that circuit operations over private inputs (e.g. a0) remain mostly unchanged together with circuit perfomances (e.g. instead of a_1 = poseidonHash([a0, epoch, rln_identifier] that increase circuit evaluation costs).

With such change, the linear SSS polynomial will change when generating concurrent proofs on different RLN applications (i.e. when employing different rln_identifier), even in case the same id_secret is employed.

[rymnc]

I think we can close this issue since Rate-Limiting-Nullifier/rln-circuits#2 resolves it

[s1fr0]

I think we can close this issue since Rate-Limiting-Nullifier/rln-circuits#2 resolves it

Correct. I'll close.