Crystal: Binding of OpenSSL elliptical curve and bignum

[xqyww123]

I'm going to bind bignum first, and if I start on elliptical curve, I will comment here.

The related contents locate in file openssl/bn.h.

--- Update ---
The work about elliptical curve mainly focuses on arithmetic like point addition and multiplication, about file openssl/ec.h.
My recent project require those function, and I think maybe it could complete some part of existing OpenSSL in std-lib.

[RX14]

There's some existing shards that cover part of this work, for example https://github.com/randomstate/openssl_ext/. You might be better off contributing to those.

[xqyww123]

Yeah, I found it, and std-lib also provides some part of OpennSSL, but the work tries to bind bignum and especially the elliptical curve arithmetic like point addition and multiplication, which isn't covered in std nor openssl_ext.
It's just my recent project require those functions, and I found since some of OpenSSL exists in std-lib, maybe I could complete some part of them. (If you think it's too heavy for std-lib, I could separate them into an isolated repo)
I'll actively integrate existing OpenSSL part in std-lib.

[RX14]

@xqyww123 the eventaul plan is to remove the OpenSSL module from the standard library, and replace it with TLS, Digest and Crypto::HMAC modules, which are abstract from the openssl API. The current OpenSSL stuff and all the openssl extensions should them be merged into one official OpenSSL shard.

That work should really be done sooner rather than later, so that there's no more ambiguity about the status of the module, but it'd hard for me to find time. For now, I suggest creating a PR for these things and I'll try to review them. Merging more features into OpenSSL is fine since it makes it easier to extract the whole thing as a shard in the future.

[xqyww123]

Okay, I'll work on it first.
Recently I have a problem, the bignum library could be built under the 32bit limbs or 64bit, determined by a macro, and also defines a commonly used type BN_LONG between int32_t and int64_t.
Some API uses BN_LONG as the argument so it should be declared in crystal lib. But I don't have a good idea to determine the actual type of it, any suggestion about it?

Should I find the head file via pkg-config and then parse it to find out which macro is enabled?
Or make a probe program to print size of the type?
Or provide a compile-time flag for cross-compilation?

[RX14]

@xqyww123 usually you'd just use

{% if flag?(:bits32) %}
  BN_LONG = Int32
{% else %}
  BN_LONG = Int64
{% end %}

to detect whether the compile target is 32 or 64bits

[bararchy]

@xqyww123 you should check the work @kingsleyh did at: https://github.com/SushiChain/crystal-ecdsa

[xqyww123]

Yes, it's maybe a usable one currently.

I'm very sorry that the plan of my code may be pushed off because I just resigned the company where the code was used. It's really sorry but I will continue to develop in Crystal community and I love it.