Support for X25519 key exchange and XChacha20 encryption about go

[pseusys]

@L11r, never mind, you didn't sound wrong! I just wanted to improve your library.
It's ok if you need time, I'm not in a hurry; moreover, I can use my fork for now. Let me know if you need help with migrating to the new curves! I can offer you my assistance with python, go and maybe js code, unfortunately I'm still not familiar with rust, however.

[kigawas]

Thanks for the update. Don't worry, the configuration is optional

[pseusys]

Is the support for XChaCha20 planned? Fyi, there exists a statdard library for it (golang.org/x/crypto/chacha20poly1305). Would be grateful for any info!

[savely-krasovsky]

The problem is that the new crypto/ecdh doesn't export important fields and methods anymore, unlike older crypto/elliptic which we use right now (which in contrast cannot be used with ChaCha20). Probably it's mostly ok to use exported version filippo.io/nistec, but I didn't try yet. Has a lot of work recently.

[pseusys]

Indeed, I have found out that secp256k1 is not supported by crypto/ecdh. However, I was able to use the older setup as-is with ChaCha20.

[pseusys]

@L11r, honestly I don't really understand why the current solution shouldn't work with XChaCha20-Poly1305 as it uses exactly the same 256-bit key length. Instead of crypto/elliptic, github.com/decred/dcrd/dcrec/secp256k1/v4 can be used, but why should it be used, since everything works as it is right now.

[savely-krasovsky]

@pseusys your solution use ChaCha20 as encryption, but key exchange still done using secp256k1. This issue is about moving to X25519. Also implementation should be unified across other ECIES libraries for Rust, JS, Python, etc.

[pseusys]

@L11r, yes, that's exactly what I have wrutten in my PR: my solution solves one of the two problems named in this issue title. As far as I understood, they are mostly independant.
Moreover, different types of symmetrical encryption are already available for the other languages.

[savely-krasovsky]

@pseusys yes, sorry if I've sounded incorrect, you contribution is good! But I guess we need to merge and release complete solution and mark it as a new major version (e.g. v3). Let me see if something has been changed recently.