libhydrogen VS OpenSSL

To quickly build something with signatures, key exchange and encryption, I'd recommend starting with libhydrogen: https://github.com/jedisct1/libhydrogen

The single round-trip initial Diffie-Hellman key exchange is susceptible to MITM attack, as has been demonstrated to me by a fan of the project. I'll be changing it to XX key exchange from libhydrogen. Either directly, or I'll use libsodium primitives to reimplement the same thing.

See if you can use this library instead of libsodium, as it'll probably work on your raspi zero: https://github.com/jedisct1/libhydrogen (Node bindings: https://github.com/trampi/node-libhydrogen-binding)

Are you possibly thinking of libhydrogen?

https://github.com/jedisct1/libhydrogen

NIST's lightweight cryptography contest is still in progress. When it finishes I'd definitely change to whatever wins. In the iterim you might want to look into the candidates. I happen to like gimli, see libhydrogen for a good library that uses it.

Wow... reading this article in full really made me lose hope in OpenSSL, the project and the library.

I was well aware of the expected inconveniences any new major OpenSSL release would trigger (esp. older, less actively maintained applications having to adapt their API usage to keep working) going in, but what the linked github issue/PR comments hint at is just... mental.

As best illustrated by https://github.com/openssl/openssl/issues/20286#issuecomment... not only seem the core developers not care about runtime performance at all, they also seem to have a completely absurd perception of their own project, esp. in relation to other, genuinely small FOSS projects.

It's just wild. I hope this can still be turned around, and OpenSSL can somehow re-emerge from this clusterfuck as the stable bedrock of web transport security that we learned to rely on from 2014 onwards.

Generate Certificates: Use OpenSSL to create a Certificate Authority (CA) and server/client certificates.

Slow adoption of QUIC is the result of OpenSSL refusing to expose the primitives needed by QUIC implementations that already existed in the wild. Instead, they decided to build their own NIH QUIC stack, which after all these years is still not complete.

They recently caved in, and OpenSSL 3.5 will finally provide an API for third party QUIC stacks: https://github.com/openssl/openssl/pull/26683

Naturally, it works differently than all the other existing implementations, as it's push-based instead of pull-based. It remains to be seen what it means for the ecosystem.

In Node, you would commonly reach for the builtin core "node:crypto" module to run cryptographic functionality like this. I wondered why that wasn't used here, but bcryptjs was. After digging into it a little, node doesn't ship with core support for bcrypt, because it's not supported by OpenSSL.

The node crypto module is essentially an API that offloads crypto work to OpenSSL. If we dig into OpenSSL, they won't support bcrypt. Bcrypt won't be supported by OpenSSL because of reasons to do with standardisation. https://github.com/openssl/openssl/issues/5323

Since bcrypt is not a "standardised" algorithm, it makes me wonder why Okta used it, at all?

I remember in uni studying cryptography for application development and even then, back in 2013, it was used and recommended, but not standardised. it says a lot that 12 years on it still hasn't been.

They pretty much told everyone that a proper integration for OpenSSL would take years. The server API seems to be in an early review state and slowly progressing.

https://github.com/openssl/openssl/tree/feature/quic-server

The encryption used by default is AES256 and SHA256 hashing from the standard OpenSSL library, both of which are widely used in cryptography. You can however use any available cipher and digest (i.e. hash) that is supported by OpenSSL (even the custom ones you provide).

Yeah, I'm using the curl wrapper crate for a Rust re-write of a C++ HTTP monitoring app I'm re-doing, because there's nothing I can find in the Rust ecosystem that even comes close to what libCurl exposes in terms of functionality and control (i.e. things like all the different timing numbers).

The wrapper crate hasn't got everything exposed for the Easy interface (I'll probably be submitting PRs to expose some missing stuff at some point), but seems good enough for me.

Only issue really I've found so far is that heap fragmentation seems orders of magnitude higher than the C++ version, and so memory useage grows quite alarmingly, but from heaptrack, that all seems to be from within openssl, with things like this (a rediculous number of heap allocations per request):

https://github.com/openssl/openssl/issues/14837

but I'm not sure why the C++ version doesn't suffer from the same issues as it's doing the same thing with HTTPS requests and is also using openssl, so I still need to look into that...

HTTP/3 support is a bit frustrating, since it's highlighted a serious split in engineering effort & focus, which has created a two-tier internet: browsers & big CDNs do support and use HTTP/3 heavily, but most small tools, servers and programming languages don't have stable built-in support at all (e.g. no support in the standard libraries for Go, Node.js, Python, etc) for either clients or servers. Even big tools like Nginx only have experimental support, disabled by default: https://nginx.org/en/docs/http/ngx_http_v3_module.html

Many years after this article was posted, OpenSSL does now have QUIC _client_ support (from 3.2: https://github.com/openssl/openssl/blob/master/README-QUIC.m...) but server support is still not available (and for Node at least, OpenSSL's approach here has been one of the main blockers for serious built-in HTTP/3 support).

There are some native libraries you can use to work around this, but they're not easy to set up in many cases and they're totally separate from each languages normal network stack. As a typical developer, the general solution is still 'just use HTTP/2 everywhere', even as HTTP/3 use on the browser web spikes higher and higher.

libcrypto is core component of the OpenSSL toolkit, and its source tree is part of the OpenSSL repo: https://github.com/openssl/openssl/tree/master/crypto