So, it comes out that almost 1/3 of the contents of a openssl private key is made out of pre-calculated CRT params that are only necessary for performance and have nothing to do with security. Very interestingly, we can corrupt all of that and still have cryptographic operations running well with the corrupted private key PEM data in openssl. #openssl
[Released] zen.nginx – NGINX Docker image with OpenSSL 3.3.4 + post-quantum Falcon/OQS support, based on Alpine.
Features:
* NGINX 1.29.x+
* OpenSSL 3.3.4 with oqs-provider (Falcon512/1024)
* Built for strict mTLS and Zero Trust
* Minimal, ready for production use
Try it:
https://github.com/zenthracore/zen.nginx
https://hub.docker.com/r/zenthracore/zen.nginx
Open for feedback & contributions!
@cloudflare 
#docker #nginx #openssl #pqc #falcon #linux #devops #security #opensource
First working Redis with post-quantum mTLS using Falcon (NIST finalist) — running in a hardened Alpine container with OpenSSL 3.3.4 + oqs-provider.
Falcon keys + certs generated inside the image, Redis launched via --tls-port, and PONGs confirmed via PQ mTLS.
GitHub: https://github.com/zenthracore/zen.redis
Docker: https://hub.docker.com/r/zenthracore/zen.redis
This might be the first public Redis instance running on PQ crypto.
@nilz hatte schon befürchtet, dass der Podcast diese Vorurteile aufgreift. Diese Einzelentwickler*innen gibt es auch, aber ist nicht die Masse.OSS ist Big Business, problematisch sind manchmal kleine Projekte, die tatsächlich wichtig sind, aber zu wenig betreut, siehe auch #OpenSSL .Diese kleinen Projekte, die nicht essentiell sind, sind nicht so bedeutend oder problematisch, wenn was schief geht. Fehler gibt es ja auch bei closed source, das ist kein Alleinstellungsmerkmal.
Just released: #swad 0.12 
swad is the "Simple Web Authentication Daemon". It basically offers adding form + #cookie #authentication to your reverse proxy (designed for and tested with #nginx "auth_request"). I created it mainly to defend against #malicious_bots, so among other credential checker modules for "real" logins, it offers a proof-of-work mechanism for guest logins doing the same #crypto #challenge known from #Anubis.
swad is written in pure #C with minimal dependencies (#zlib, #OpenSSL or compatible, and optionally #PAM), and designed to work on any #POSIX system. It compiles to a small binary (200 - 300 kiB depending on compiler and target platform).
This release brings (among a few bugfixes) improvements to make swad fit for "heavy load" scenarios: There's a new option to balance the load across multiple service worker threads, so all cores can be fully utilized if necessary, and it now keeps lots of transient objects in pools for reuse, which helps to avoid memory fragmentation and ultimately results in lower overall memory consumption.
Read more about it, download the .tar.xz, build and install it .... here:
I added OpenSSL encryption into script for NS exchange between servers with Pihole 6.
I need help. First the question: On #FreeBSD, with all ports built with #LibreSSL, can I somehow use the #clang #thread #sanitizer on a binary actually using LibreSSL and get sane output?
What I now observe debugging #swad:
- A version built with #OpenSSL (from base) doesn't crash. At least I tried very hard, really stressing it with #jmeter, to no avail. Built with LibreSSL, it does crash.
- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM
- The thread sanitizer finds nothing to complain when built with OpenSSL
- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)
- It even complains when running with a single-thread event loop.
- I use a single SSL_CTX per listening socket, creating SSL objects from it per connection ... also with multithreading; according to a few sources, this should be supported and safe.
- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless
- I *could* imagine sharing the SSL_CTX with multiple threads to create their SSL objects from *might* not be safe with LibreSSL, but no idea how to verify as long as the thread sanitizer gives me "delusional" output 
Where could I find docs for historical versions of #OpenSSL? I'm trying to set up a CA for #RetroComputing machines with OpenSSL 0.9.6b, but the little bit of documentation that came with it isn't telling me much. Basically need to create a CA certificate I can put on client machines so that they won't complain about self-signed certs.
More interesting progress trying to make #swad suitable for very busy sites!
I realized that #TLS (both with #OpenSSL and #LibreSSL) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a #lockfree queue as opposed to one protected by a #mutex. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed. 
So I read some scientific papers 
... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. 
Maybe it could do even more, didn't try yet.
Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...
(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: https://dl.acm.org/doi/10.1145/248052.248106
May’s #Tumbleweed update rolled out #QEMU 10.0 for improved virtualization 
and #OpenSSL 3.5.0 with post-#quantum #crypto Security got serious with #CVE fixes 
#openSUSE https://news.opensuse.org/2025/06/02/tw-monthly-update-may/
Prepare to poo your pants.
OpenSSL provides a few helpers to compare certificates.
X509_cmp(), which returns 0 on a match, and
EVP_PKEY_cmp(), which returns 1 on a match.
It's OK, tan-coloured landmines are safe to step on. Olive-coloured landmines will explode and you will die.
#apt-listchanges: News
---------------------
#curl (8.13.0-2) unstable; urgency=medium
The curl #CLI is now back to using #OpenSSL, instead of #GnuTLS:
HTTP/3 support is still there, compared to the GnuTLS curl CLI.
The performance of HTTP/3 on OpenSSL is not as good, but it's also not used
by default.
-- Samuel Henrique <samueloph@debian.org> Sun, 06 Apr 2025 22:13:18 +0100
