Open oleganza opened 4 years ago
I picked the "sign:"
prefix because of https://github.com/w3f/schnorrkel/issues/39 In fact I believe that's not a serious concern, but adjusting seemed easier than checking any details at the time.
It's true "SigningContext" kinda sucks. :( I originally asked users to supply the label, but then this happened hastily: https://github.com/dalek-cryptography/merlin/pull/44
Oh, i forgot about 'static
slices for labels.
Inside the protocol 'static
labels work fine, of course. It's just when dynamic languages want to create a transcript that you encounter problems: https://github.com/paritytech/schnorrkel-js/issues/12
As an aside, I needed this weirdness so that ed25519 and schnorrkel could be batch verified together.
@burdges does it even make sense to provide $label
parameter for plain message-oriented API? If one wants to get fancy with composition and domain-separation, they should use transcript directly, no? I'd keep it as simple as current signature schemes do - message in, signature out.
I suppose not really.. I wanted us to use stronger domain separation everywhere in polkadot, but others preferred Blake2 and no Blake2 STROBE variant exists, and we support other signature schemes too. Ideas leak. :P
Are all these commits sequenced identically?
Would be cool to make Schnorrkel and Starsig compatible with each other. Here's a table of differences.
"dom-sep", "starsig v1"
"proto-name", "Schnorr-sig"
"dom-sep", "schnorr-ristretto255"
"X"
"sign:pk"
"pk"
"R"
"sign:R"
"R"
"c"
"sign:c"
"c"
Convenience wrapper for byte-oriented API:
"Starsig.sign_message"
"SigningContext"
"schnorr-ristretto255-message"
append($label,$msg)
append("", $label)
append("sign-bytes",$msg)
append("msg",$msg)