they already have a good reply with understandable reasons and let me give you yet another reason with a different perspective. you must not even want to use a cryptography library for any cryptocurrency unless you want to open yourself to a lot of attack surface!
all these crypto libraries including "swift-crypto" are defined to do cryptography for general purpose, but the cryptography used in bitcoin (and by all its copies like ethereum,...) is special purpose. for example look at Open SSL which is the most popular crypto library. it was used in bitcoin core and was the source of a lot of bugs in bitcoin none of which even matter in general use like SSL encryption in your browser with certificates,...
look at BIP62 for a bunch of these issues!
Topic: Help convincing Apple to add "Bitcoin Curve" - secp256k1 to Swift-Crypto (Read 171 times)
February 19, 2020, 11:39:07 AM
February 19, 2020, 09:18:41 AM
(@Moderators I didn't wanna post this in the Technical sub-forum because I wanted as much help/visibility as possible - not only for tech enthusiasts. But do feel free to move to other subforum)
About two weeks ago I posted a proposal on Apple's (quite new) Github repo Swift-Crypto about adding SECG Elliptic Curves, especially secp256k1 a.k.a. the Bitcoin curve.
Three days later one of the core contributors and Apple employees shut down my proposal (scroll down in the thread on Github for his reply).
I tried to be strategic when I wrote my proposal, to not focus too much on any specific DLT, why I did not call the proposal e.g. "Add the Bitcoin curve". However, I did mention Ethereum with name, that is not because I love Ethereum and hate Bitcoin - far from it. The reason why I mentioned Ethereum with name was that I was building up my argument, or my approximation really, where I claimed that 95% of all cryptos rely on the curve secp256k1. Not knowing how much the contributors of swift-crypto knows about the crypto sphere, I quickly needed to mention many coins are ERC20 tokens, thus using secp256k1.
Anyway, my proposal has been rejected... Which kinds of sucks. So I was hoping bitcointalk users could help convince Apple to change their minds - which is something they opened up for in their response (end of the second paragraph: "Please note that if circumstances change and the cryptography landscape changes, we may revisit this decision.") - sooner, rather than later.
Why should we care about this Apple library? Well, hopefully, you read my proposal on Github and got some answers there... But it really boils down to making it easy for Swift (the programming language that is) developers such as myself to develop crypto wallets and applications using ECDSA. Currently, there exists no really great ECC library which can easily be integrated into a Swift project.
I was hoping we could try to change Apple's mind. One of the reasons my proposal was denied was that they don't wanna add too many curves - especially curves which do not have "a sufficient set of use-cases to justify (adding it)". I believe sepc256k1 has a much broader user base than many of the currently supported curves, here is the list of curves swift-crypto currently supports:
I have not been able to find any major usage of neither P384 nor P521, but maybe my Googling skills fail me. If it is indeed true that neither P384 nor P521 is widely used, then that might be a really good argument as a response to Apple, to persuade them to possibly remove any of these curves and replace with secp256k1 - if it is indeed true that is the major reason for their rejection of my proposal. There can, of course, be other reasons behind the rejection - some kind of hidden agenda (something Apple is good at)... Then I will resort to adding secp256k1 in a fork of the repo - but that is really not as powerful/advantageous as having it part of Apple's repo.
How can you help? Well I can come up with three ways:
I have started writing a response, which I can share with you later if you are interested. But I think it will be more powerful if lots of different people get involved and try convincing Apple, rather than just me.
Thanks for reading!
About two weeks ago I posted a proposal on Apple's (quite new) Github repo Swift-Crypto about adding SECG Elliptic Curves, especially secp256k1 a.k.a. the Bitcoin curve.
Three days later one of the core contributors and Apple employees shut down my proposal (scroll down in the thread on Github for his reply).
I tried to be strategic when I wrote my proposal, to not focus too much on any specific DLT, why I did not call the proposal e.g. "Add the Bitcoin curve". However, I did mention Ethereum with name, that is not because I love Ethereum and hate Bitcoin - far from it. The reason why I mentioned Ethereum with name was that I was building up my argument, or my approximation really, where I claimed that 95% of all cryptos rely on the curve secp256k1. Not knowing how much the contributors of swift-crypto knows about the crypto sphere, I quickly needed to mention many coins are ERC20 tokens, thus using secp256k1.
Anyway, my proposal has been rejected... Which kinds of sucks. So I was hoping bitcointalk users could help convince Apple to change their minds - which is something they opened up for in their response (end of the second paragraph: "Please note that if circumstances change and the cryptography landscape changes, we may revisit this decision.") - sooner, rather than later.
Why should we care about this Apple library? Well, hopefully, you read my proposal on Github and got some answers there... But it really boils down to making it easy for Swift (the programming language that is) developers such as myself to develop crypto wallets and applications using ECDSA. Currently, there exists no really great ECC library which can easily be integrated into a Swift project.
I was hoping we could try to change Apple's mind. One of the reasons my proposal was denied was that they don't wanna add too many curves - especially curves which do not have "a sufficient set of use-cases to justify (adding it)". I believe sepc256k1 has a much broader user base than many of the currently supported curves, here is the list of curves swift-crypto currently supports:
- P256 aka secp256r1 (used by NEO)
- P384 aka secp384r1
- P521 aka secp521r1
- Curve25519
I have not been able to find any major usage of neither P384 nor P521, but maybe my Googling skills fail me. If it is indeed true that neither P384 nor P521 is widely used, then that might be a really good argument as a response to Apple, to persuade them to possibly remove any of these curves and replace with secp256k1 - if it is indeed true that is the major reason for their rejection of my proposal. There can, of course, be other reasons behind the rejection - some kind of hidden agenda (something Apple is good at)... Then I will resort to adding secp256k1 in a fork of the repo - but that is really not as powerful/advantageous as having it part of Apple's repo.
How can you help? Well I can come up with three ways:
- Upvote my proposal on Github (create a Github account if you don't have one)
- Being polite, positive and constructive: Write a response in the thread, giving fact-based reasons why secp256k1 should be added (I really think being polite, constructive and fact-based is important, I do not want to instigate. I JUST want the curve added and I think any rudeness in the Github thread will just harm "the cause".)
- Apart from the activity on Github you can share the Github issue link to DLT enthusiast with a Github account and involve them
I have started writing a response, which I can share with you later if you are interested. But I think it will be more powerful if lots of different people get involved and try convincing Apple, rather than just me.
Thanks for reading!
Jump to: