Resolve #84

[skaunov]

That was a larger one. 😅
Among other it

• bumps non-breaking versions,
• finalizes documentation including the example,
• improves test(s),
• adds signing capability.

[Divide-By-0]

Can we add a note in docs or something that a protocol should set this message to be unique, and unique per nullifier? I.e. a protocol might put the name of the question being voted on here along with their protocol name for a ZK vote.

[skaunov]

That's a good one! What does message reuse brings? Is it only replay or would it let signing other messages without having the secret; or maybe anything else?

[Divide-By-0]

No replay but you can deanonymize someones nullifier from the other place they posted and correlate that their identity must overlap with the other groups nullifier anonymity set.

[skaunov]

Why the point $r$ isn't included into the hash then? It would make each signature unique and move this foot-gun away from those employing the protocol... 🤔

[Divide-By-0]

Because then the nullifier wouldn't be deterministic! We need that property. We can potentially set a default in smart contracts to add the blickhash as part of the message.

[skaunov]

I totally trust you just trying to understand.

Deterministic as "to know c beforehand of signing"; or is it just the fact that V2 wouldn't work since it lacks the point $r$ value? Or something else?

I mean I kind of don't see yet the essential difference if signer adds to the message point $r$ instead of the info/data you mentioned. 🤔

[Divide-By-0]

Is there a reason the user has to pass in the RNG? I wonder if it would help ease of implementation to have a version in which the RNG is determined inside of the function itself? Maybe I'm not as familiar with how RNG is treated in rust.

[skaunov]

This particular part is conforming to RustCrypto, outside of the module I preserved choice of the CRNG as they're sensitive thing, and it's a good practice to offer downstream to use whatever they see fit (according to the trait bounds).

On the other hand if you feel like simplifying it further I see no problem to just hard-code the system CRNG like the example shows inputting it. I guess downstream wouldn't have the control for the thread in which that will be running. But that path/choice is mainly for no-std (embedded) environment where instantiating the CRNG is custom to the platform. Anyway downstream would be able to sign with the PlumeSigner which offers the choice.

[Divide-By-0]

What if we exposd a fn for signing with no RNG argument that filled in a preset RNG as a call to the existing fn, kind of like a default arg?

[skaunov]

That's exactly what I'm talking about. Just initializing the system RNG in sign_v1 leaving PlumeSigner for those who need detailed control.

[Divide-By-0]

For sure!

[Divide-By-0]

Is there some confirmation that this signature function corresponds exactly to the compute all inputs function in JavaScript?

[skaunov]

Is there some confirmation that this signature function corresponds exactly to the compute all inputs function in JavaScript?

Only the fact that I have checked manually. X) Basically the values are taken from there. But everybody are invited to have another look; it's always better.