Re: Draft Schnorr Secp256k1 Cryptosuite for Data Integrity

st 19. 2. 2025 v 21:16 odesílatel Manu Sporny <msporny@digitalbazaar.com>
napsal:

> On Wed, Feb 19, 2025 at 10:07 AM Will Abramson <wip.abramson@gmail.com>
> wrote:
> > Is a draft of a Cryptosuite for producing Data Integrity proofs using
> Schnorr signatures with Secp256k1 keys according to the latest proposed
> recommendations from the VCDM.
>
> That's awesome, Will! It'll be nice to standardize a non-ECDSA /
> Schnorr signature scheme.
>
> Digital Bazaar supports adoption of this work item when the time
> comes. We're happy to also try and collaborate on implementations/test
> suites in time.
>
> > As well as its ability to support multisig - which needs some more
> thought about how exactly to describe (if you want to) a verificationMethod
> is a multisig.
>
> Yes, this is one of the more interesting capabilities that this
> approach would allow us to pursue.
>
> > As you can see from our resository -
> https://github.com/dcdpr/data-integrity-schnorr-secp256k1 - this
> specification started from the EdDSA Cryptosuite specification and changed
> it to be specific to Schnorr Secp256k1. So much of the work was already
> done by the community and the VCDM - thank you for that! I hope it is okay
> that I borrowed from this excellent starting point.
>
> Yes, perfectly fine to re-use that spec given it's been through quite
> a bit of implementation and review. It does raise the question wrt.
> how much was copy-pasted and if we should generalize those algorithms
> into the base Data Integrity specification to maximize re-use. That
> can be a part of the v1.1 work on Data Integrity in the VCWG later in
> this year.
>
> > One aspect of the spec that is worth drawing attention to is our
> definition of the secp256k1 x-only Multikey prefix -
> https://dcdpr.github.io/data-integrity-schnorr-secp256k1/#multikey.
> Should this be registered somewhere else?  From the CID spec, it states
> anyone can define their own Multikey prefix so I figured this would be
> okay. But clearly we wouldn't want other keys to also use the same value
>
> Yes, the spec can define its own Multikey prefix, and my hope is that
> we split the Multiformats stuff out of the CID spec eventually. I'll
> note that the secp256k1 pubkey value is 0xe7 (don't know what the
> varint encoding is off of the top of my head):
>
> https://github.com/multiformats/multicodec/blob/master/table.csv#L93
>
> ... so you'll want to use that instead of the one you have in the spec,
> IIUC.
>
> > This is still very much a draft and we would welcome any external
> contributions from those interested in supporting this specification.
>
> The only thing that jumped out at me was the length of the cryptosuite
> name (I know, I know... just can't help bikeshedding names). Some
> thoughts:
>
> * I think the inclusion of "rdfc" and "jcs" in cryptosuite names was a
> mistake -- we were trying to go for something like "ezsign-2023"
> instead of using "crypto babble" and we ended up exactly where I was
> hoping we wouldn't end up: "ecdsa-jcs-2019" (bleh, gross). I think we
> did better with "bbs-2023"... can we try to do better here?
>
> * I don't think it's useful to put "secp256k1" in the name, again, too
> much crypto babble.
>
> * To suggest something a bit provocative, what about just
> "bitcoin-2025" for the JCS version and "bitcoin-rdf-2025" for the RDF
> version?
>

Did some say bikeshedding? :)

I dont think replacing secp256k1 with bitcoin is a good idea.  Many more
things than bitcoin use secp256k1 including nostr, and a number of bitcoin
forks.

Also noting that xonly coord (as used in bitcoin taproot/schnorr) has a
both positive and negative value on secp256k1, but only one is taken.  This
is different from compressed keys which have the sign encoded as 02 or 03.


>
> Exciting stuff, Will! Looking forward to seeing it mature and go
> standards track!
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>