Re: Draft Schnorr Secp256k1 Cryptosuite for Data Integrity

st 19. 2. 2025 v 16:08 odesílatel Will Abramson <wip.abramson@gmail.com>
napsal:

> Hi all,
>
> I want to announce a new Data Integrity Cryptosuite that Digital Contract
> Design and Legendary Requirements have been developing as part of an effort
> to create a new and improved Bitcoin based DID method.
>
> As many of you may know, Bitcoin uses secp256k1 keys to authorize Bitcoin
> transactions. It initially supported ECDSA signatures, but in the last few
> years it has added support for Schnorr signatures.
>
> We wanted to enable these secp256k1 keys, which have extensive adoption
> and library support, to be usable within DIDs and VCs. Specifically,
> enabling a secp256k1 key could be included in a DID document as a
> verificationMethod and used to create proofs on documents like a VC.
>
> While there have been some earlier attempts to support secp256k1 keys and
> proofs, these all appeared outdated and not really maintained.
>
> This specification:
> https://dcdpr.github.io/data-integrity-schnorr-secp256k1/
> <https://dcdpr.github.io/data-integrity-schnorr-secp256k1/>
>
> 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.
>
> We chose to support Schnorr signatures rather than ECDSA because of its
> better security and efficiency characteristics (See
> https://hashpire.io/garden/EdDSA_vs_ECDSA_vs_Schnorr for a good short
> overview). 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. As well as how to produce a multisig
> proof. Interestingly however, verifying a multisig Schnorr Data Integrity
> proof would be exactly as described in this current specification. The
> verifier would not, and does not need to, know how the proof was created.
>
> 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.
>
> 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
>
> This is still very much a draft and we would welcome any external
> contributions from those interested in supporting this specification.
>
> *We intend to propose this as a CCG Work Item and continue developing and
> refining the specification under the CCG. *
>

+1


>
> Finally, for those who like to get into the code the repository includes
> Jupyter notebooks that walk through an implementation of the Cryptosuite
> step by step -
> https://github.com/dcdpr/data-integrity-schnorr-secp256k1/tree/main/notebook_examples
> <https://github.com/dcdpr/data-integrity-schnorr-secp256k1/tree/main/notebook_examples>
>
> There is also a very rough stab at a Python library for adding Data
> Integrity proofs to documents using the Schnorr secp256k1 Cryptosuite -
> https://github.com/LegReq/di-schnorr-secp256k1-python.
>
> Would love to hear what people think, especially if folks are interested
> in helping to move this work forward.
>

You may be aware of the Nostr project, which uses taproot and schnorr, to
create a social network.  I chair the nostr community group at the w3c [1],
and we have been thinking about registering a DID method for a while.  We
have also begun some early work on web authentication using schnorr
signatures [2].  Perhaps there would be some overlap.  Looking forward to
following your work.

[1] https://www.w3.org/community/nostr/
[2] https://nostrcg.github.io/http-schnorr-auth/


>
> Thanks,
> Will
>
>
>
>
>
>

Received on Wednesday, 19 February 2025 15:14:47 UTC