Feat: Add Schnorr signature scheme

[yelhousni]

No description provided.

[ivokub]

There is a key leakage/forgeability problem imo.

[ivokub]

Hmm, I think this is incorrect. In Schnorr we use the hash for Fiat-Shamir challenge. If hFunc==nil, then we do not hash signer randomness into challenge and get a weak instance. Depending on the attack, we either leak secret key or allow forging signatures.

In description, we should rather think as the challenge as H1(P || H2(m)), where hFunc refers to H2 not H1. H1 should be fixed per-curve to fill the whole scalar element.

[ivokub]

I thought about it. I think the secret key is safe, but still allows forgeability.

[yelhousni]

I think there is no point into hashing the message (H2) before hashing its concatenation with P (H1), as we consider arbitrary long messages. My initial thought was that if the user uses nil as hFunc it would mean he did H(P || m) prior to signing, and we just convert it to and integer. But I agree that if it opens room to ambiguity we should clear this up. So either:

• We remove the hFunc argument from the interface and enforce a hash function inside Sign() and Verify() for all signature schemes --> but we wouldn't be able to replace with a SNARK-friendly hash in gnark if needed, or
• if hFunc == nil then we use an encoded hash inside Sign() and Verify(), otherwise we use the hFunc provided by the caller --> but we would always compute a hash and can't delegate this (e.g. out-circuit in SNARKs), or
• hFunc would mean H1 as in your example and we always do H2 --> same we can't delegate H2 but the interface and implementation would be similar across signature schemes.

[ivokub]

One option is if there is some nice SNARK-friendly instantiation of the Fiat-Shamir challenger for Schnorr signatures. https://eprint.iacr.org/2020/915.pdf says there is (Theorem 2.4 and Construction 2.5), but as I understand, imo requires a (one-time?) trusted setup. But if it is true, then we can fix H1 and hFunc gives H2.

[ivokub]

See comment about Fiat-Shamir in Sign.

[ivokub]

@yelhousni - actually, maybe we could change interfaces such that the hash functions are a property of the key, not runtime parameter to Sign and Verify. So, when we have schnorr.GenerateKey then we feed all the properties we want (hash function H1, H2 etc.) and then later just call pk.Sign(msg) and vk.Verify(sig, msg). We could also embed the information in the marshalled keys and so when unmarshalling all the properties are also applied.

I think this is also a bit more future-proof as for example RSA has a lot of parameters you can tweak (not that we want to get into RSA-land, but just in case) and it really doesn't make sense to pass them manually around everywhere. And if we do not pass any options when generating the keys, then we choose defaults (e.g. SHA256 for ECDSA etc.). Does it makes sense? If so, then I would create a new issue to design it further.

[yelhousni]

Does it makes sense? If so, then I would create a new issue to design it further.

Yup that makes sense.

[0xtinkle]

In this route, I guess, it's also worth to think about standardizing an interface or struct (e.g. SignatureParams) that bundles H1, H2, and any SNARK-friendly hash flags. Could help simplify key serialization too.