- From: Tony Arcieri <bascule@gmail.com>
- Date: Sat, 25 Mar 2017 15:55:18 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>, Christopher Allen <ChristopherA@blockstream.com>
- Message-ID: <CAHOTMVLsh=PPYm5t7BCL9=_u06ng3orGEVt4bA-OM6v_vqVK2A@mail.gmail.com>
On Sat, Mar 25, 2017 at 3:41 PM, Manu Sporny <msporny@digitalbazaar.com> wrote: > > What would you suggest we switch to that would simultaneously keep > compatibility with the Bitcoin community while utilizing more modern > signature schemes? This is new work, so we have a very good opportunity > to change things at this point. > I would recommend Blockstream's secp256k1 Schnorr signature algorithm, although unfortunately I don't think there are existing standards describing it published through any sort of standards body. Also, we've been interested in deploying Schnorr signatures for a while > but lack the expertise to pick the right parameters for the Signature > Suite... would you know enough about Schnorr to help us put together a > Schnorr Signature Suite? (we can implement, we just need someone (you?) > to check our math). In all of my personal and professional work we are using EdDSA, which is a Schnorr scheme and standardized in RFC 8032. I am not particularly interested in doing any standards work around secp256k1 until the preliminary RFC 8032-style legwork around the secp256k1 Schnorr signature scheme is in place. That said, I don't think there's presently any effort underway to e.g. put together an informational RFC about this scheme and publish it through the CFRG. secp256k1 also has the disadvantage of a multitude of twist security and off-curve point attacks when used in an ECDH context. I feel like using it for signatures is a slippery slope towards using it for D-H and creating schemes with attacks other implementations are automatically hardened against per default. This is already happening with e.g. the Lightning Network: they are attempting to shoehorn secp256k1 into the Noise protocol. -- Tony Arcieri
Received on Saturday, 25 March 2017 22:56:11 UTC