- From: Christopher Allen <ChristopherA@lifewithalacrity.com>
- Date: Thu, 13 Jan 2022 13:57:34 -0800
- To: Brent Shambaugh <brent.shambaugh@gmail.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CACrqygD0RG7KnQytZWq5EVoySep96=WBoVMxzjwe6eZTfX6Ksw@mail.gmail.com>
On Thu, Jan 13, 2022 at 1:25 PM Brent Shambaugh <brent.shambaugh@gmail.com> wrote: > FWIW, I have the NIST curves in this PR: > https://github.com/ceramicnetwork/js-ceramic/pull/1884 . I booked ETH > Denver this year: Feb 11- 20th, so I will be focusing on that for the time > being. If you are talking about what I think you are talking about, maybe I > can help. > Thanks Brent. Your NIST curve code might be useful later, but right now we leverage the solidly reviewed secp256k1 C library used by Bitcoin as we don't have the resources to review cryptographic code / side channels / etc. nearly to the level they do. Our project is actually much simpler — just convert the public key already internally generated by the app to the multibase format that did:key uses, then encode that in whatever human-readable URI format it needs, and then create unit tests and compatibility tests to make sure they are the same as the reference keys in the did:key method spec. The lead developer @WolfMcNally of keytool-cli could probably whip this out fairly quickly, but he is not as familiar with did:key and did:web compatibility issues, and is working on a different code base right now. I thought this might be an easy starting project for a journeyman developer in the DID ecosystem, I have some funding available, and I'd like to confirm how easy it is for others to contribute to our keytool code base (for instance, it currently doesn't support 25519 or ristretto keys or signatures, but I'd like it to someday). -- Christopher Allen P.S. Here are the key derivations currently supported by keytool-cli: [image: image.png]
Attachments
- image/png attachment: image.png
Received on Thursday, 13 January 2022 21:58:29 UTC