New API Proposal: Add SECG curves, especially `secp256k1`

[Sajjon]

New API Proposal: Add secp256k1curve

Motivation:

I REALLY think we should add EC Curve secp256k1.

I can make a PR - if I know Apple will not reject it automatically just because it is a SECG curve and not a NIST curve?(or due it being "the Bitcoin curve")

If we were to allow SECG curves (the whole crypto community would love it if we did), then it would make sense to renamed the existing curve using NIST naming to use SECG naming instead, see Appendix A in RFC4492

Why add support for secp256k1? Well, Crypto currencies are on the rise (despise crypto winter of 2018/2019), and App Store contains lots of wallets already - a vast share of which are crypto currencies using the secp256k1 (since most coins are ERC20 tokens based on Ethereum, and all coins in top 8 use sec256k1, I approximate 95% of the total market cap of cryptocurrencies rely on secp256k1).

Since there are no native Swift lib for secp256k1, we see lots of unsafe libs, such as my own EllipticCurveKit, hyugit/EllipticCurve, EllipticSwift, all of which, including mine are unsafe.

One of the most popular projects is a wrapper of C library secp256k1, named BitcoinKit, but it does many things, including HD Wallet and is a bit messy.

So in order to protect users of iOS crypto wallets from losing funds due to errors/unsafe code, I think it is important that we add this curve.

Importance:

No we cannot use this curve today, but it is easy to add it I can make a PR.. I've dabbled in Crypto a bit before EllipticCurveKit, PRs into BitcoinKit.

[Lukasa]

Thanks for this! Can you begin by filling out the API proposal template? This would help focus the discussion more clearly.

[Sajjon]

@Lukasa of course, how silly of me, I got so excited when I saw this, and directly clone and found no secp2561, started coding a PR and realized I ought to ask first, but missed reading CONTRIBUTING.

Before I saw your comment I started with a rationale, I'm updating to conform to the template.

[Sajjon]

@Lukasa Is this format OK? Need any more input? Should I change anything?

Thanks!

[Lukasa]

This update is fab, thanks. We’ll have a conversation and get to our feelings about whether secp256k1 is in-scope for addition to Swift Crypto.

[paulmillr]

It’s pretty bad to NOT implement this. secp256k1 is one of a few elliptic curves that are really popular, today.

If you’re open sourcing a library, but don’t want contributions for a curve that’s used in every third project — what’s the point? We can continue to use our own libs...

[Lukasa]

Thanks very much for this proposal! You did a good job laying out the use-cases for secp256k1 (and, in #22, RIPEMD) support in Swift Crypto.

After careful consideration, my colleagues and I have concluded that we do not believe secp256k1 support meets the bar for entry into the Swift Crypto API at this time. Before I explain why in more detail, I want to clarify that this is not because we believe that secp256k1 is flawed or that we think it has no use-cases, and we absolutely believe there is space in the open-source Swift ecosystem for a library that provides good APIs for accessing this curve. Unfortunately, we do not believe that Swift Crypto is the right place for this implementation. Please note that if circumstances change and the cryptography landscape changes, we may revisit this decision.

In the case of Swift Crypto, our explicit goal is to build a library that focuses on constructions that are, amongst other criteria, “broadly useful”. An important corollary of this goal is that we need to avoid providing too many constructions that do similar things with unclear distinctions. To take an example from a different part of the API surface of this library, each additional AEAD cipher construction we add to this library forces users to ask themselves whether they should use that construction, instead of another.

In the case of the elliptic curves, we already have a reasonably large number of them. This sets the “broadly useful” bar for each additional curve we add even higher, as the curve now needs not only to be useful enough to be included but also to justify adding to the decision matrix for users who need to pick a curve for their use-cases. The question is, does secp256k1 enable a sufficient set of use-cases to justify adding it to the API?

In this case, secp256k1 is used almost exclusively in the cryptocurrency community. Outside of that community, secp256k1 is a highly unusual curve to use. This means that it has a fairly narrow set of use-cases in which it is a reasonable default. This adds asymmetrical API risk to the API: users building cryptocurrency wallets will immediately know that they need secp256k1 and can dismiss the other choices, while users building other constructions (of whom there are vastly more) will now need to research and consider secp256k1 to validate whether it is suitable before they dismiss it. The burden of this new API falls much more heavily on the more-common use-cases. For better or worse, P-256 has much wider deployment than secp256k1, and therefore has an easier time justifying its presence in Swift Crypto than secp256k1 does.

Additionally, BoringSSL does not have an optimised implementation of secp256k1. We can have BoringSSL implement it using the custom curves functionality, but this will make the performance of secp256k1 substantially worse than the optimised NIST curves currently exposed via Swift Crypto. That’s an unfortunate and surprising performance cliff to hit for unsuspecting users who may reasonably assume that the performance of these curves could be expected to be broadly similar.

In this instance, then, our recommendation is that you continue to pursue a high-quality secp256k1 implementation outside of Swift Crypto. If the API design of Swift Crypto is appealing for your intended use-case, the API design here is entirely available under Apache 2.0 and may freely be imitated in third-party libraries. As noted above, we will continue to keep an eye on the ecosystem and will be willing to revisit this decision if things change.

We understand that this is disappointing, but we believe that this choice will give the best results for everyone involved: those who need access to this primitive will almost invariably know to search for it, and we would love for them to be able to find a high quality implementation in the Swift open source ecosystem. We look forward to seeing the community's work in this space.

[paulmillr]

Folks, it's pretty simple — Apple is doing everything in their power to slow down adoption of crypto projects.

That's disappointing, because they'll add it anyway in a couple years, when the adoption would be higher. Whatevs.

[KevinVitale]

"Please note that if circumstances change and the cryptography landscape changes, we may revisit this decision." – @Lukasa.

Where does this leave the contributing community? Google describes BoringSSL as: "...a fork of OpenSSL that is designed to meet Google's needs.". You (and the team) could probably saved yourself many more drawn-out spats by being equally transparent about this project's goals.

[Lukasa]

You (and the team) could probably saved yourself many more drawn-out spats by being equally transparent about this project's goals.

I understand your frustration, but I don't believe there is a problem with transparency here. We have said in every project forum, including this repository's readme, that it is not a goal of Swift Crypto to support every cryptographic primitive in use today. This necessarily means that proposals for some (indeed, most) primitives will be refused.

On the issue of introducing specific additional elliptic curves to the supported set, we are not drawing bright lines in the sand ruling in or out specific curves and committing to the decision forever. Good stewardship of a library like this is necessarily fluid: as the landscape shifts, decisions can and should be revisited. However, we consider it vital to keep the supported set small to avoid non-expert users drowning under the weight of curve choices. At this time, we believe that rules out secp256k1. If the calculus changes here (e.g. because secp256k1 becomes widely used in less-specialised contexts, or other supported curves are removed) we will re-evaluate.

Where does this leave the contributing community?

We continue to welcome proposals from the community. We will continue to evaluate each proposal on its specific merits at the time of its proposal. The fact that we said no to this proposal does not mean we'll say no to others.

[Sajjon]

@Lukasa I see what you did here (This is an EC SPKI object with an unsupported named curve.) 😅

[Cyclic]

Thanks very much for this proposal! You did a good job laying out the use-cases for secp256k1 (and, in #22, RIPEMD) support in Swift Crypto.

After careful consideration, my colleagues and I have concluded that we do not believe secp256k1 support meets the bar for entry into the Swift Crypto API at this time. Before I explain why in more detail, I want to clarify that this is not because we believe that secp256k1 is flawed or that we think it has no use-cases, and we absolutely believe there is space in the open-source Swift ecosystem for a library that provides good APIs for accessing this curve. Unfortunately, we do not believe that Swift Crypto is the right place for this implementation. Please note that if circumstances change and the cryptography landscape changes, we may revisit this decision.

In the case of Swift Crypto, our explicit goal is to build a library that focuses on constructions that are, amongst other criteria, “broadly useful”. An important corollary of this goal is that we need to avoid providing too many constructions that do similar things with unclear distinctions. To take an example from a different part of the API surface of this library, each additional AEAD cipher construction we add to this library forces users to ask themselves whether they should use that construction, instead of another.

In the case of the elliptic curves, we already have a reasonably large number of them. This sets the “broadly useful” bar for each additional curve we add even higher, as the curve now needs not only to be useful enough to be included but also to justify adding to the decision matrix for users who need to pick a curve for their use-cases. The question is, does secp256k1 enable a sufficient set of use-cases to justify adding it to the API?

In this case, secp256k1 is used almost exclusively in the cryptocurrency community. Outside of that community, secp256k1 is a highly unusual curve to use. This means that it has a fairly narrow set of use-cases in which it is a reasonable default. This adds asymmetrical API risk to the API: users building cryptocurrency wallets will immediately know that they need secp256k1 and can dismiss the other choices, while users building other constructions (of whom there are vastly more) will now need to research and consider secp256k1 to validate whether it is suitable before they dismiss it. The burden of this new API falls much more heavily on the more-common use-cases. For better or worse, P-256 has much wider deployment than secp256k1, and therefore has an easier time justifying its presence in Swift Crypto than secp256k1 does.

Additionally, BoringSSL does not have an optimised implementation of secp256k1. We can have BoringSSL implement it using the custom curves functionality, but this will make the performance of secp256k1 substantially worse than the optimised NIST curves currently exposed via Swift Crypto. That’s an unfortunate and surprising performance cliff to hit for unsuspecting users who may reasonably assume that the performance of these curves could be expected to be broadly similar.

In this instance, then, our recommendation is that you continue to pursue a high-quality secp256k1 implementation outside of Swift Crypto. If the API design of Swift Crypto is appealing for your intended use-case, the API design here is entirely available under Apache 2.0 and may freely be imitated in third-party libraries. As noted above, we will continue to keep an eye on the ecosystem and will be willing to revisit this decision if things change.

We understand that this is disappointing, but we believe that this choice will give the best results for everyone involved: those who need access to this primitive will almost invariably know to search for it, and we would love for them to be able to find a high quality implementation in the Swift open source ecosystem. We look forward to seeing the community's work in this space.

Adding secp256k1 to swift-crypto should be reconsidered. Banking is adopting crypto, NFTs have become mainstream, and having a library such as SwiftCrypto adopt this curve will help a lot of developers build leaner, cleaner, and more reliable software. In addition, the argument that developers might be confused or have to research the performance differences when they're selecting the appropriate curve, by adding a popular, additional option, is a red herring. Please reconsider adding secp256k1 as soon as possible and help businesses and developers cleanup their swift dependencies.