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.

New quircs

The small footprint quirc QR decoding lib has merged some fixes that makes it way more reliable when scanning flipped QR codes. I merged these fixes myself to opmsg-qr (which forks quirc), so its in turn also more reliable when scanning opmsg QR-code keys sent via phone messengers. Give it a try! Painless opmsg persona sharing via Signal and such. Still recommended to use camera with auto-focus. Scanning QR codes with opmsg-qr however needs some seconds, compared on what you experience by scanning with your phone. So, just experiment with it to get a feeling and how it could be useful.

Armbian trickery

Some new root magic for IoT ARM boards. This time for Armbian, in a  very generic way so to run on almost all boards.

PSC SOCKS trickery

I submitted a patch to PSC SOCKS handling. The bug that was fixed could lead to poor browsing experience. By now, its not necessary anymore to click the reload button to finish loading of some sites.

More IoT bugdoors

 More LPE trickery for IoT boards can be found here.

tinkershell trickery

 After a couple of years, I published a new one of the famous boomsh exploits. This time for an IoT devel board, running a Debianish distribution for ARM. https://github.com/stealth/tinkershell

More PSC trickery!!

I updated psc to include SOCKS4 and SOCKS5 support, so you can now do crazy things like web browsing remote networks from within a modem dialup shell or portshell (even multihop), effectively upgrading a simple portshell to a SSH like e2e pty shell with the ability to forward TCP and UDP ports.

This finally merges code into PSC that I started back in early 2000's, when I was in need to have TCP connections via modem dialups that actually did not have ppp to obtain an IP address to browse from.

Port Shell trickery

 

Added new feature to my old long running project psc. You may now forward TCP or UDP ports in a similar way as with ssh -L. The cool thing: You don't even need an IP address or network connection to the remote hop. An UART or modem connection will suffice. As long as you have a tty session, you can now slip TCPv4, UDPv4, TCPv6, UDPv6 through it and appear with your connections as if they were made on the remote end.

A demo video is on asciinema.