Add optional prover-generated nonce value to increase privacy

[awoie]

I raised that issue a while ago and I was not able to create a PR. The idea here is that this nonce would actual help protecting the prover's privacy by producing different signature values for the same challenge. This increases privacy in certain scenarios and is best practice in a lot of other protocols. E.g. the ISO 18013 series, or even JWTs have that in form of a jti.

[awoie]

I don't have a good term for it other than nonce. The term definition should explain why this is useful in certain scenarios to increase privacy.

[msporny]

Ok, then we'll re-introduce nonce and say that it is a "proof creator supplied value" that can be used for the purposes that you outline above.

[dlongley]

I think nonce should not be reintroduced. It should be included (embedded however the cryptosuite desires) in the proofValue instead -- because it shouldn't be exposed to the application. It's fundamentally different from challenge in that way.

Some signature algorithms already introduce "per message secret nonces" (like ECDSA) and those are internal details.

[dlongley]

If I'm misreading the above -- and the suggestion is that an application developer would provide this value instead of it being done internally from within a privacy-preserving cryptosuite, then I'm ok with reintroduction. It seems like a complexity we wouldn't want application developers to have to deal with, but perhaps there are use cases where they have no choice because they must use a cryptosuite that doesn't otherwise support such a feature.

[awoie]

I think nonce should not be reintroduced. It should be included (embedded however the cryptosuite desires) in the proofValue instead -- because it shouldn't be exposed to the application. It's fundamentally different from challenge in that way.

Some signature algorithms already introduce "per message secret nonces" already like ECDSA and those are internal details.

Yes, but sometimes the app developer has no other choice than using a deterministic signature scheme and in that case, an extra nonce helps with increasing privacy.

[dlongley]

I think nonce should not be reintroduced. It should be included (embedded however the cryptosuite desires) in the proofValue instead -- because it shouldn't be exposed to the application. It's fundamentally different from challenge in that way. Some signature algorithms already introduce "per message secret nonces" already like ECDSA and those are internal details.

Yes, but sometimes the app developer has no other choice than using a deterministic signature scheme and in that case, an extra nonce helps with increasing privacy.

Ok, that's a good reason to reintroduce it, +1.

[TallTed]

For the eventual PR, I suggest "value supplied by the proof creator" rather than "proof creator supplied value".

[msporny]

PR #122 was merged to address this issue, closing.