MinaProtocol / mina

Mina is a cryptocurrency protocol with a constant size blockchain, improving scaling while maintaining decentralization and security.
https://minaprotocol.com
Apache License 2.0
1.99k stars 531 forks source link

Incorrect description of Schnorr signatures in doc #1106

Closed daira closed 2 years ago

daira commented 5 years ago

At https://github.com/CodaProtocol/coda/blob/master/docs/lifecycle_of_a_payment_technical.md#signatures Schnorr signatures are described incorrectly. I'm not sure precisely which variant you're using, but typically (in EdDSA-style Schnorr variants) the signature consists of a compressed curve point (sometimes just an x coordinate) and a scalar, not an uncompressed curve point. In the original Schnorr scheme it was a hash and a scalar.

https://crypto.stackexchange.com/questions/34863/ec-schnorr-signature-multiple-standard

jkrauska commented 5 years ago

@daira Thanks for bringing this up! We will take a closer look at this and see about improving it.

imeckler commented 5 years ago

Hi Daira -- the scheme we're using is basically (as far as I know) the original Schnorr scheme where a signature consists of a hash and a scalar. In the actual code, the hash is just treated as a scalar (and in the scheme one just interprets the hash as a scalar) so I think that's why that document describes a signature as a pair of scalars. It's true that this isn't the most efficient as far as serialization goes if a full scalar with lots of zeroes at the end is being used instead of a 256 bit hash, and the distinction should probably be made.

imeckler commented 5 years ago

For reference, here is a description of the scheme we're using (section 3)

daira commented 5 years ago

Right, but the link I pointed to says:

So what is a signature? Open up signature lib's checked.ml and scroll to module Signature within module type S. It's a non-zero point on a curve, aka a pair of two curve_scalar values.

That's incorrect: it is indeed two curve_scalar values, but they don't represent a non-zero point on the curve. It should say something like:

[...] It's a pair of two curve_scalar values, representing the two parts s and h of a Schnorr signature as described in section 3 of this paper.

daira commented 5 years ago

Incidentally, https://github.com/CodaProtocol/coda/blob/master/docs/lifecycle_of_a_payment_technical.md#public-key has LaTeX markup that renders incorrectly as Markdown.

antonio-fr commented 3 years ago

Looking at the code base, the doc seems right, and this replies is wrong. @imeckler suggested that the Mina Schnorr flavor (pointed as described there) would be 2 scalars as (h, s), s being r + d.h with h = H(R, M) similar to BSI or ISO/IEC 14888-3 EC-SDSA standard. But it turns out, looking at the code of Mina, that it uses the Schnorr BIP flavor or EC-FSDSA. And this signature output (Rx, s), which is indeed a non-zero point on the curve (x coordinate) and a scalar. S being k + d.H( Rx || Pk || M ). This signature sheme is very similar to EdDSA, rather than the Schnorr "original" scheme. The confusion might come from the fact the signature scheme used for Bitcoin BIP is called "Schnorr", and more generally in the crypto world, is more like EdDSA. Anyway the BIP standard is even explaining the 2 families types of Schnorr signatures, and the choice for the second one. Note that there are 7 incompatibles standards regarding Schnorr signatures, hence this opened issue to clarify the one used in Mina.

Actually the doc is not crystal clear, as the curve_scalar pair values of the signature is not a point on the curve, but rather just a scalar pair with the first one is the x coordinate of a point. We can also see this signature as a point on the "full plane", and this is the case for all Schnorr signature with the (b, b) output form.

The best option for doc would be to make it clearer, I propose :

The signature is made by 2 modular scalars : the x coordinate of the nonce point, and the scalar secret computation.

And the doc should give a reference to the exact standard use, which seems to be this one. (Except this uses Pallas curve parameters, instead of the 256k1 parameters ?)

daira commented 2 years ago

https://github.com/MinaProtocol/mina/blob/develop/docs/specs/signatures/description.md now describes the variant used precisely, thanks.

daira commented 2 years ago

May I suggest that you mention FROST and ROAST (which is a wrapper around FROST providing robustness) as possible multisig schemes in https://github.com/MinaProtocol/mina/blob/develop/docs/specs/signatures/description.md#multisignatures-and-threshold-signatures ?

shimkiv commented 2 years ago

cc @imeckler @joseandro