does v has a ECDSA lib ?

[zhfnjust]

[JalonSolov]

It has https://modules.vlang.io/crypto.ed25519.html (which was just created recently) but not ecdsa. Yet.

[zhfnjust]

ecdsa is usd by bitcoin, which is most popular cryptocurrencies

[blackshirt]

We have lack of ecdsa based ecc for vlang.
Maybe there are some progress on it, i really dont know
For other crypto, likes @JalonSolov says, we already have ed25519 in stdlib (and other crypto stuff for v, curve25519 for ecdh, chacha20poly1305 for aead encryption).
Just for info, if we look at https://www.susanka.eu/coins-crypto/ there are multiple cryptocurrencies backed by eddsa, especially, ed25519, thats i think its a good one because we already have it.

[ismyhc]

I’d be willing to sponsor anyone with the ability to bring ECDSA to V. If you are interested please reach out.

[ismyhc]

Hi @ismyhc! I'm Subhomoy and I've written most of the code for the math.big module.

Before this I've worked on revamping the rand module.

Currently, I have a few ideas for big.Integer including primality checking and stuff but it wasn't prioritised so it's on the back burner. Same for big.Decimal.

Work on math.big will be essential for implementation of cryptographic algorithms. If there's a motivation/prioritisation through sponsorship, I'm ready to resume work on this!

Hey! If a precursor to bringing EDCSA functionality into V starts with math.big then I'm will to sponsor that work. Ultimately I'd like to see the functionality needed to handle BTC crypto functions as I'm wanting to build a btc module. Key generation, signing, verification etc.

In addition to math.big would you also be working on ECDSA?

[hungrybluedev]

@ismyhc Yes that is the ultimate intent. Having the math.big module see real world use. Sorry if I wasn't clear. I am willing to work on ECDSA as well.

[ismyhc]

@ismyhc Yes that is the ultimate intent. Having the math.big module see real world use. Sorry if I wasn't clear. I am willing to work on ECDSA as well.

Great! Could you write up a rough plan and cost estimate?

[hungrybluedev]

@ismyhc Yes I'll send it privately to your email. The gmail account mentioned on your GitHub profile.

[hungrybluedev]

@ismyhc I've sent you the estimate through email. Let me know your thoughts in a reply to that mail.

[bstnbuck]

I am working on a solution to implement TLS in V. Especially such crypto modules have to be maintained permanently, which is why I will probably use OpenSSL and the Win32 API functions in the form of a wrapper. It makes sense to implement ECDSA for this purpose as well. (And as soon as V is stable enough to write the functions in pure V).

I estimate with the implementation until the end of August this year.

See #11806

[ismyhc]

Are you suggesting just wrapping the ECDSA functionality from openssl? We would still need BigNum type in V though right?

[bstnbuck]

Until V does not receive many more changes and the functions are stable, this is a possibility.
The problem with crypto functions is not the functionality itself, but also being free of vulnerabilities. By continuing to make major changes, this could then be put on the back burner. And that should not be the case.

Still, I agree with implementing ECDSA in pure V. Unlike TLS itself, major changes are less likely.

[JalonSolov]

While wrapping C libs is a quick & dirty (often very dirty) way to get something to work, I'd rather see @hungrybluedev finish a pure V version of ECDSA.

OpenSSL is already used with V, but it has been nothing but trouble trying to get Windows users to be able to install it properly. A pure V version wouldn't have this problem (or many others related to trying to shoe-horn C libs into it that don't necessarily work well on all systems).

[ismyhc]

I do agree. Which is why I'd be willing to sponsor or at least co-sponsor the effort to build a pure v version.

[bstnbuck]

Yes, that's true @JalonSolov! Using C functions is not always nice. However, it does provide the actuality and also the speedy implementation for temporary functionality.
Still as mentioned above, I happily agree with the idea of implementing ECDSA in pure V.

OpenSSL works without further problems in Linux and also MacOS. The typical problem Windows is not easy to fix. Also the installation of OpenSSL for Windows users is unattractive. Here the Win32-API functions (especially Schannel) should be used more. The functionalities are all there (not only TLS or ECDSA, but also RSA and many more).

The static integration of OpenSSL in the thirdparty section I don't see as a good thing. After all, with every release the changes have to be embedded.

[Wajinn]

What's going on with the pure V versions of ECDSA and RSA? Know there is thirdparty solutions, but curious on if anybody is still or going to do the pure V ones.

[medvednikov]

It will be done by the end of the month. I'm on it (working on go2v to translate crypto modules).

[ismyhc]

It will be done by the end of the month. I'm on it (working on go2v to translate crypto modules).

@Wajinn I recently wrote a module that wraps secp256k1 c library. It's focused around the needs of nostr, but you may be interested.

https://github.com/ismyhc/vsecp256k1

Go2v would be amazing though. There are a lot of crypto packages that could help!

[Wajinn]

@medvednikov and @ismyhc

Thanks guys. Good to see this activity.

[JalonSolov]

V has a ecdsa module now.

[ismyhc]

Nice!!! 🙏

This is really cool. If OpenSSL had shcnorr signature support I could ditch my custom secp256k1 module.

Might be interesting to look into this implementation that uses OpenSSL and includes schnorr. Maybe a good candidate for c to v conversion. If I get some time I'll investigate.

https://github.com/metalicjames/cschnorr