- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 25 Mar 2017 18:41:54 -0400
- To: Credentials Community Group <public-credentials@w3.org>
- Cc: Tony Arcieri <bascule@gmail.com>, Christopher Allen <ChristopherA@blockstream.com>
BCC: public-webpayments-ig Hey Kim, Tony, apologies for the W3C mailing list maze, but the Verifiable Claims discussion is happening in the Credentials CG now: https://www.w3.org/community/credentials/ The ECDSA Signatures discussion should probably happen in the W3C Digital Verification Community Group... but that group hasn't really spun up yet: https://w3c-dvcg.github.io/ On 03/24/2017 06:11 PM, Tony Arcieri wrote: > I'm sorry if this is a sidebar in this issue Don't be... we really appreciate the feedback you provided. :) > but is there a particular reason why you're using Koblitz signatures > and, perhaps more concerning, why you're using ECDSA? You said it in your email... Bitcoin compatibility. That community wanted a signature suite that was compatible with Bitcoin in general. Also, DISCLAIMER: All of the technologies we're talking about are experimental and are expected to blow you foot off if you put them into production without understanding the consequences of the design decisions you've made. > The CFRG has selected Ed25519 (RFC 8032) as the next-generation high > security curve. If performance is the concern, more modern > alternatives like FourQ will exceed e.g. secp256k1's performance. If there is a desire to create an Ed25519 Signature Suite for Linked Data signatures, we'd be happy to help someone create it. I imagine that in time, that will exist as well. > The only reason to choose secp256k1 (I assume?) today is > compatibility with Bitcoin. Yes, that's why the signature suite uses it. > But that's less concerning than this: New protocols should NOT be > using ECDSA. ECDSA has repeatedly failed in practice, has many > failure modes modern signature schemes are not vulnerable to, and > now that the Schnorr patents have expired is completely obsolete. 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. 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). -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Rebalancing How the Web is Built http://manu.sporny.org/2016/rebalancing/
Received on Saturday, 25 March 2017 22:42:30 UTC