This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As per the request on the mailing list[1]. I was wondering if the crypto group may consider adding support for secp256k1 in the browser Named Curve dictionary. http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary enum NamedCurve { // NIST recommended curve P-256, also known as secp256r1. "P-256", // NIST recommended curve P-384, also known as secp384r1. "P-384", // NIST recommended curve P-521, also known as secp521r1. "P-521" }; Over the last year, there has been a significant increase in deployment for this curve. It's used in bitcoin and many other crypto currencies. Bitcoin deployment now numbers in the millions of users and hundreds of companies. There are also free software implementations in most languages. For more background on Koblitz curve used by bitcoin see: https://bitcointalk.org/?topic=2699.0 I think that at the time this group's charter was written, crypto currencies were relatively unknown. However, over the last year they have exploded in popularity. "Bitcoin" was one of the top 100 searches globally last year, and even has made it into the Oxford English Dictionary. It would be fantastic if this curve were able to make it into the registry, and User Agents were given an opportunity to implement. The Free Software community could perhaps offer some code, where that applies. I understand that it would be a feature at risk, thank you for at least taking the time to give it some consideration. Thanks! Melvin [1] http://lists.w3.org/Archives/Public/public-webcrypto-comments/2013Dec/0000.html
Discussed on 2/10 conference call. We need feedback from implementors indicating that they wish to implement this before including it in the specification, given that it is not widely implemented in crypto libraries.
Could this be looked at again? Last response was waiting for feedback from crypto implementors. Currently secp256k1 is supported in the following SSL/TLS libraries now Botan NSS openssl LibreSSL PolarSSL JSSE The three other curves are all all have parameters which do not define how they were generated. secp256k1 curve has some great advantages in faster signature verification and how the values were determined for the curve. (i.e. not random). http://www.ietf.org/rfc/rfc4492 The curve has had a lot of eyes on it with lots of hardware and software supporting this curve. With discovery of backdoor's in NIST's random number generator (https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html ) I would like to see a determined parameter curve instead of a "random" curve option. Thanks
In order to progress towards exit to Last Call for the Web Crypto API, the chair suggests the following resolution for that bug. resolution : Bug CLOSED. This problem will be addressed by the extension bug 25618 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618. If none objects before the 20th of Oct @20:00 UTC, this resolution will be endorsed.
I respectfully object to this one being closed. I'd like to support Melvin Carvalho's suggestion (as further supported by Myron Davis in a later comment) that support for secp256k1 in browser Named Curve be added, and I agree with the many concerns that have been raised about NIST (regarding Schneier's and other remarks on Dual_EC_DRBG which are linked to in Melvin's suggestion). As described by Hal Finney in the bitcointalk post shown above in Melvin's remarks, secp256k1 is "a variant on a so-called Koblitz curve, and 1 means it is the first (and only) curve of that type in the standard." In that same bitcointalk thread where Hal Finney made those remarkes, the user ByteCoin in January of 2011 stated, "One plausible option for a future bitcoin-like system is to allow a selection from a numbered range of pre-selected curves. Smaller transactions or balances could use smaller keysizes if necessary." [[ ByteCoin is associated with development of BCN, which uses the Cryptonight algorithm (based from CryptoNote with adaptive limits) / a schnorr ring signature in the curve25519 group ~ and has received favorable remarks from some bitcoin developers (see remarks both at http://news.ycombinator.com/item?id=7765455 and also at http://download.wpsoftware.net/bitcoin/wizardry/brs-arbitrary-output-sizes.txt ]] It seems to me that Melvin Carvalho's suggestion would not conflict with Mark Watson's suggestions in bug 25618 relating to a "supported curves list." I would be curious to know if the proposal by Mark Watson, which "considerably limits the extensibility for elliptic curves to those with various similarities to the existing NIST curves" (from comment 57 at bug 25618) would enable Melvin Carvalho's suggestion to be incorporated as part of the larger proposal which Mark Watson described here: http://lists.w3.org/Archives/Public/public-webcrypto/2014Oct/0128.html However, that proposal did seem limiting and should be reconsidered or changed to ensure that the kind of curves used in decentralized, distributed systems (bitcoin (BTC), bytecoin (BCN) and hundreds of others) are not inadvertently marginalized as the proposal becomes formalized.
As an additional note regarding curve25519 referenced in my above comment: "curve25519 was published by the renowned cryptographer Dan Bernstein in "Lecture Notes in Computer Science" ( http://link.springer.com/chapter/10.1007/11745853_14 ) and according to Google Scholar it has 114 citations. On its Wikipedia page you could have found out that it extensively used by Apple in iOS (...) It's probably going to be one of the major groups used for ECDH (elliptic curve Diffie-Hellman - the stuff you need for fast perfect forward secrecy) in TLS 1.3 and some even argue to ditch all the NIST curves in its favor" (quoted from: https://news.ycombinator.com/item?id=7766537 which was published approximately 150 days ago)
We have now closed bug 25618 in such a way that new curves of various kinds can be added as extensions specifications, so I propose we close this bug. This does not imply a decision not to specify the requested curve, but reflects the fact that new curves will be specified in extension specification, not in the base specification.
My comment may be too late: but chiming in with my support for secp256k1. Frankly, there are no use cases for the Web Crypto API more compelling than that of Bitcoin. Bitcoin stores billions of dollars worth of real value today. That value is mostly transacted using non-web clients because of the inherent insecurity of most web applications. The Web Crypto API has a massive opportunity to help change this and make web-based bitcoin possible by adding native support for secp256k1. Bitcoin really is the killer app for WebCryptoAPIs. The working group is foolish not to incorporate it.