SNI trickery

We at c->skills know how the Hase läuft and therefore made a writeup on SNI probing and blocking.

Parallel find trickery

Since a parallel version of nftw() already existed inside my greppin project, it was only little effort to add a parallel find: spot

New commits trickery

 I commited some changes to some of my gh projects:

psc is now using an embedded AES and SHA-512 implementation, in order for easier builds for embedded systems w/o proper SDK support. E.g. it is now super easy to have Android binaries built with it, w/o messing with BoringSSL builds. It also contains a base64 en/decoder on the remote side callable via pscr -E or pscr -D for convenience. Last not least, you can script psc sessions via pscsh. Something similar you propably know from screen with shared sessions.

For harddns, my DoH solution - that was one of the first Open Source DoH implementations available at all - I added NXDOMAIN replies for PTR queries, in order to keep up with newer net-utils packages on current distributions which always try to reverse-resolve obtained A records to PTR records. I also updated the shipped default config to remove the PowerDNS DoH servers, as they recently have shutdown this service :(

Anniversary trickery

Some of you probably already noticed in past, but almost exactly one year ago, I founded my own company:

You can find more details about the exact services at our gh landing page. In order to celebrate our 1y, I pushed new commits to our performance flagship greppin. It is now basically lock-free and runs faster than ripgrep.

Thanks to our clients who made this possible! If things go well as before, I will also alloc() a merchandise budget, so you may ask me for free tee-shirts at the conferences.

OpenSSL 3.0.0 API trickery

 

I refactored opmsg for the new OpenSSL 3.0.0 API and put it into the openssl3-dev branch. Master branch is still the main development branch and both branches produce 1:1 identical output of messages, so one can cross-over test them. Over the long run it is probably necessary to switch to OpenSSL 3.0, but the downside is that it will lose compatibility with the LibreSSL API.

On the plus side, I learned a lot of the inner workings of OpenSSL while refactoring my own code. Including misleading man pages.That will definitely give me an adavantage for the next crypto project code review. :)

Wish you a nice pre-xmas time!

DevOps trickery

I released some DevOps research about self-replicating code  spreading across gits.

Post-Quantum opmsg trickery

I have added patches to opmsg to implement PQC during the transitioning phase. Adding PQC sounds easier than it actually is, as there are several (administrative) problems:

* So far, no PQC algo has been standartized. Everything is     still floating and in progress.

* Several PQC open-source projects exist, such as  OpenQuantumSafe which implement the candidate algos, but which recommend to not use their impl in production code.

* Some patches for OpenSSL 1.1.0 exist such as for NTRU, but only cover the 1.1 API which will soon be denounced.

* OpenSSL 3.0 on the rising, changing the ENGINE API in favor of "Providers", but I didn't see any PQC code in it.

* Big tech companies making their own PQC patches and tests for marketing reasons but these are not usable for opmsg as they only cover TLS handshakes for their own good.

Sounds to me like I could only bet on the wrong horse by making any decision.

Therefore, I decided to agnostically add PQC support by following recommendations of the BSI when migrating crypto to PQC for the time being. That means extending opmsg Brainkey Personas by a second type "brainkey2" which adds a symmetric salt in the ECDH Kex. This is transparent to the user. At the same time, I ban non-AEAD symmetric algorithms for future encrypts (decrypts still work for compat) and extend the coverage of the AEAD to the entire message, including the header. That means that the entire opmsg is not only integrity protected by the ECDSA signature, but also by the AES-GCM MAC. The PFS property and everything else stays the same. The new default calgo is now "aes256gcm".

I am sorry I had to kick bf, cast5 and ripemd160 from newly encrypted messages, but these algos are outdated anyway. It should still be possible to decrypt all previous messages, despite of ciphers and persona types.

I have to check how OpenSSL develops, as I want to keep compatibility with LibreSSL API. So I have to be careful when adding new symmetric ciphers with AEAD capability such as EVP_aria_256_gcm().

multiple stuff trickery

I added some new features and workarounds to some of my projects:

* New features for crash, namely TCP and UDP port forwarding similar to psc and some other neat stuff

* better support for brainkey personas in opmsg, as well as workarounds for a recent OpenSSL regression that does not allow to set ECDH privkeys to NULL any longer when doing the PFS Kex

harddns updates

Google DoH again changed their JSON replies, so I had to adjust my harddns parsing. Otherwise you will get NXDOMAIN when asking 8.8.8.8.

DGC trickery

In order to re-find all the necessary documents easily, I created a repo to have the EU vaccination certificate stuff in a single place. I will add code, keys and threat analysis as I go.