Re: Draft Schnorr Secp256k1 Cryptosuite for Data Integrity

Thanks Manu. Some more thoughts inline.

On Wed, Feb 19, 2025 at 8:15 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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.
>


We would love to see support for this Cryptosuite added into the DB's
https://github.com/digitalbazaar/jsonld-signatures library. Greg Bernstien
had some great pointers for how I could add some proper test vectors to the
repo, I will try to do that soon.



>
> > 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.



Yes, I think that makes sense to think about. One thing that stood out to
me as I was creating the spec is the duplication between the jcs and rdfc
Cryptosuites. In this case, all the algorithms are the same apart from the
canonicalization algorithm used.

Even across Cryptosuites, the algorithms defined in the spec
(transformation, hashing etc) are typically the same. The difference is the
actual hashing, canonicalization and signing algorithms. E.g. sha256, jcs,
bip340-schnorr.



>
> > 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.
>

I did not realize that Mutlikey prefixes were already defined by
multiformats, thats cool. I thought the CID spec was the first place to
define them.

Although, as a few people mentioned, the Cryptosuite uses 32 byte x-only
public keys, rather than the standard 33 byte compressed secp256k1 public
key. We chose to do this to make it clear that these verificationMethods
should only be used to produce BIP340 schnorr proofs. Whereas if we used
the standard format, they could be used for both Schnorr and ECDSA proofs.

If that path sounds sensible, then I guess we should be registering the
prefix in the Multicodec table.


>
> > 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?
>


Yes, I also dislike the name as it currently stands. Too long and wordy.
One option I thought about was "bip340-2025".


>
> 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/
>
>