Re: Draft Schnorr Secp256k1 Cryptosuite for Data Integrity

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?

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/

Received on Wednesday, 19 February 2025 20:13:21 UTC