Closed daira closed 2 years ago
@daira Thanks for bringing this up! We will take a closer look at this and see about improving it.
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.
For reference, here is a description of the scheme we're using (section 3)
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
withinmodule type S
. It's a non-zero point on a curve, aka a pair of twocurve_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 partss
andh
of a Schnorr signature as described in section 3 of this paper.
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.
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 ?)
https://github.com/MinaProtocol/mina/blob/develop/docs/specs/signatures/description.md now describes the variant used precisely, thanks.
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 ?
cc @imeckler @joseandro
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