Making library set more generic by supporting more curves or switching to X25519

[savely-krasovsky]

Yes, I understand, that you probably want to keep them as lightweight and easy as possible, but secp256k1 as default is not cool for this aim in my opinion. Yes, it's better than NIST P-256, but according to http://safecurves.cr.yp.to/ it has some flaws.

I can recommend two ways:

1. Making API more complex to support many curves (at least the most popular).
2. Switch to Curve25519 (X25519) that consider by many cryptographers as better choice.

The first way is a slippery slope I guess; afterwards we will want to add KDF choice and so on and so on. You should follow KISS principle here I hope.

In my opinion the second way can be presented just as a new major version. ECIES is just a framework to build secure cryptosystems and in many cases there is no difference what algos are under the hood.

In case of Golang we already have semiofficial X25519 library (https://golang.org/x/crypto/curve25519). There is also cool set of libraries for Rust (https://github.com/dalek-cryptography/x25519-dalek). But there are no battle ready libraries for JS, AFAIK. Cannot say anything about Python.

[kigawas]

Good catch, maybe we can add 25519 curve support first, then consider how to support multiple curves