Full OpenSSL Implementation

[sempervictus]

The current OpenSSL bindings are rather scarce, normal crypto and validation ops available in Ruby, Python, etc arent there. At present, the openssl.cr shard is also out of order at least on arch due to missing functions in the libssl version compared to what that shard was written for, leaving no good options on the table. Brixen's rubysl openssl might be a good reference implementation, although its written in C bindings instead of FFI.

[RX14]

Also, in the future we're probably going to remove the OpenSSL module in the stdlib, and replace it with small implementation-portable modules for specific tasks, for example Digest, TLS, MAC etc. The full abilities of openssl definitely shouldn't make it into the stdlib for crystal 1.0. Having a shard to point people to would be a good thing as we're removing OpenSSL.

[sempervictus]

I understand the desire for a lean stdlib without deps on giant and fluctuating libraries. Problem for crypto is twofold: who will implement it correctly/prove it? How do we use the language now? I just had to drop crystal (thankfully syntax is almost ruby and I use rbx for concurrency/channelized ops) for a fast messaging poc being shown to industry controlling companies because I need to decrypt data encrypted by a client using common RSA ops with certs/keys. Trivial in any other language, and not optional even for a poc in 2018. If developers can't even write pocs (and I won't get into the massive workflow slowdown from trying to navigate the api and not having a real repl), then the language doesn't get the shakedown it needs during this critical early phase. Benchmarks are cool, so is adoption... ;-). If the plan is to implement native crypto, I'm all for, but that could literally take years to write and proof. Implementation of a proper openssl interface until then will get a lot more adoption, testing, feedback, and bug genocide done in the meantime. If crystal had this today, we would be showing a global scale comms pipeline poc using its awesome speed for the back end client (works fine with plain text, super fast actually), this time around, Rubinius gets to shine (plus actual parallelism which I was doing with subprocs here and no shared state). This language looks very promising, but suffers from a major case of perfect being the enemy of useful in a real world setting.

[RX14]

@sempervictus Oh I absolutely realise the need for a full openssl binding.

I just absolutely think it shouldn't be in the stdlib, it should be an official shard.

[sempervictus]

Ah, sorry, i took that to mean the idea was to not have it at all. If its not in stdlib sometime down the line, replaced by native crypto namespaces, whats the plan for proper crypto in contexts like those required by stdlib - https, auth, etc. There's a bunch of hashing, sym, and asym crypto in play relying on library-defined constants to be compatible with other languages.

…

On Mon, Jan 29, 2018 at 2:22 PM, Chris Hobbs ***@***.***> wrote: @sempervictus <https://github.com/sempervictus> Oh I absolutely realise the need for a full openssl binding. I just absolutely think it shouldn't be in the stdlib. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#87 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRPjKGNFwMR93JuZ8-dgX3B-ZErZRcuks5tPhqPgaJpZM4Rv8R_> .

-- Boris Lukashev Systems Architect Semper Victus

[RX14]

@sempervictus we'll provide generic interfaces over simple, easy to use functions like TLS, SHA1, HMAC, etc in the stdlib.

These will be implemented likely at first with openssl, but the implementation will be generic so that for example libressl's libtls can be supported, or gnutls (for TLS), or libsodium (for other crypto stuff), or maybe native implementations. It doesn't matter what implements these APIs, just that they can be implemented by other libraries, instead of being deeply tied to openssl's API. The latter is what I want to avoid getting into 1.0