crypto.ecdsa: improvement to safety checking, unified signing (and verifying) api to accept options.

[blackshirt]

This PR was next iteration from previous PR 23407 thats already merged.
In this current PR, the main changes was integration of signing and verifying API to support options. The current behaviour was not changed with this iteration, This PR also contains some bits of improvement to the crypto.ecdsa module, in the form:

• Adds some bits of example to the readme file.
• Improves some documentation to the exposed routine(s).
• Add safety check to the new_key_from_seed, and also add some random test to check safety.
• Fix new_key_from_seed for handling seed with leading zeros bytes and align with PrivateKey.seed(). See this bug.
• Unifies signing and verifying api to accepts SignerOpts. The current behaviour was not changed.
• Changes of default value of hash_config of SignerOpts into .with_no_hash to align with current behaviour of signing (verifying)
• Add privkey_from_string routine to allow loading private key from pem-formatted string.
• Add pubkey_from_string routine to allow loading public key from pem-formatted string.
• Split key_free into explicitly PublicKey.free and PrivateKey.free methods. I have found issues with this current approach.
• Add an example file.
• Some bits of code restructurization.

Please give its deep of review @medvednikov, @spytheman, @JalonSolov, @felipensp and others .
Thank you

[huly-for-github]

Connected to Huly®: V_0.6-21893

[blackshirt]

@spytheman : i think the failing CI jobs was similar to the previous PR ..should we remove the additional test ?

[spytheman]

No. Use instead #define OPENSSL_API_COMPAT 0x30000000L if you are going to define it at all.
That is already used in vlib/net/openssl/openssl.c.v:3:#define OPENSSL_API_COMPAT 0x30000000L .
If you do not use the same define, then programs that import net.openssl and import crypto.ecdsa will not be congruent, and that can lead to hard to diagnose problems.

[blackshirt]

I have not check it deeply, but the most of low level ec_key method likely would be deprecated, on recent version of openssl ..
I would check it and change accordingly

[blackshirt]

Its facing issues until deprecated low level wrapper migrated into higher level recommened in 3.0.
I dont know the best way to deal with it ...

[blackshirt]

I think the feasible way for this workaround just not defined it at all here (in this module). Its still work with openssl and ecdsa together,
but will fail if we use -cstrict option on the backend.

[spytheman]

As a side note @blackshirt, I would appreciate it a lot, if future changes to this module, are done gradually, in smaller PRs, that contain focused changes.

Those are much easier to make, easier to review, faster to check on the CI (the chances of encountering edge cases and bugs are much smaller), and ultimately faster to merge (and less painful to revert, if needed).

[blackshirt]

As a side note @blackshirt, I would appreciate it a lot, if future changes to this module, are done gradually, in smaller PRs, that contain focused changes.

Those are much easier to make, easier to review, faster to check on the CI (the chances of encountering edge cases and bugs are much smaller), and ultimately faster to merge (and less painful to revert, if needed).

Yeah, i think i would be stick with small changes ..Thank you for your suggestion brother..
I think a lot of thing when it first written was using deprecated-recently with the current release of openssl, its need a big rewrite to use new higher-level supported API ..i can do that, but i think its can be done in slowly

[blackshirt]

@spytheman @medvednikov : i sent changes as suggested review, but some of them can not be applied ...i'm also add a warning to readme about tha facing issues. Feel free to hold this PR if its not good enough to be merged..

[spytheman]

@spytheman @medvednikov : i sent changes as suggested review, but some of them can not be applied ...i'm also add a warning to readme about tha facing issues. Feel free to hold this PR if its not good enough to be merged..

At this point, I am tempted to just close it, and then wait for smaller and more focused PRs for each of the individual points in your description :-| .

[spytheman]

However I will not close it, since I know how demoralizing it can be to have a big PR closed :-|, so I will just strongly oppose any attempt to expand the scope of it even further, and wait for the remaining issues to be fixed.

[blackshirt]

However I will not close it, since I know how demoralizing it can be to have a big PR closed :-|, so I will just strongly oppose any attempt to expand the scope of it even further, and wait for the remaining issues to be fixed.

Thanks...I think its the last commit i made. One thing myself was not satisfied was the issue related with OPENSSL_API_COMPAT. Its hard to be done correctly without rewriting most of the deprecated wrappers, so i left as is.
I think its still compilable and works seamlessly even with net.openssl together.

import net.http
import crypto.ecdsa

fn main() {
    resp := http.get('https://url4e.com/unknown')!
    dump(resp.body)

    pvkey := ecdsa.PrivateKey.new()!
    signature := pvkey.sign(resp.body.bytes())!
    
    pubkey := pvkey.public_key()!
    verified := pubkey.verify(resp.body.bytes(), signature)!
    dump(verified)
}

works as expected

$ openssl --version
OpenSSL 3.3.2 3 Sep 2024 (Library: OpenSSL 3.3.2 3 Sep 2024)
gitpod ~ $ v -d use_openssl -cc clang run http.v
[http.v:6] resp.body: <html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

[http.v:13] verified: true

The still remaining problems was comes from when build with -cstrict option beyond up of openssl 3.0