Logging pipelines carry some of the most sensitive operational data inside modern infrastructure. If an attacker can read or manipulate those streams, they gain deep visibility into the system.
The Internet has always been a battlefield. It was even designed to be war-resistant and with commercialisation in the late 1990s it became also attractive to a large number of additional malicious actors. Today, cyber warfare is in a sense even stronger than a hot war. It now is important to keep up with bad actors. In the age of quantum computing, this also means support for post quantum cryptography (PQC).
Post quantum is not that common today. In order to change that a bit, we will ensure that rsyslog and the Adiscon product line – WinSyslog, rsyslog Windows Agent, EventReporter, and MonitorWare Agent – support post-quantum cryptography. We will start with rsyslog, because it has the quickest release cycle. There actually already is a pull request open, so expect rsyslog post quantum cryptography support very soon.
What will be done?
Note that we decided to support post quantum cryptography only on platforms like Debian 13 that already provide solid support. And: if you want to go to the battlefield, do you really want old tools? Me not. Anyhow, is there actually demand for older stuff, we will reconsider if there is market need.
We focus on securing over-the-wire protocols. This is probably the most important part for any logging pipeline component. We also know from experience that users tend to strongly prefer file system and similar encryption tools for logs and temp files over the respective rsyslog capabilities. To me this is a logical choice to stick to a well-known feature set that must be employed in any case.
Why Post Quantum Support Now?
You may wonder. Well… we had post quantum on our mind for quite a bit, but it did not come up as a top priority. You know about the hot war Russia has started against the Ukraine. You may not as well be aware of the cyberwar Russia has started against … well, at least the EU, but there either is a lot of collateral damage or they have other parts of the world, including some other very strong countries (you know what I mean) also on their list.
Next comes Iran and its allies who were always active in cyber and have increased their activity recently for obvious reasons.
As far as the security sources I read the type of attack has also shifted a bit. While there was a lot of cyber espionage with limited sabotage in the past, very recently it seems to have shifted to be more sabotage heavy. At least this is my point of view.
There is also a real risk right now: it is called “harvest now, decrypt later”. Attackers capture encrypted traffic today and store it until quantum computers can break current cryptography. You will not notice today. But you will when the harvested data is turned against you later. So better address the root issue as soon as possible.
Of course post-quantum does not immediately change everything. But the situation demands being ready for the future, and there is probably no better day to start with that than today. I need to admit that the new US cyber strategy, as brief as it is, has provided the final motivation to begin right now. It really demands post-quantum priority and I agree this is necessary.
The Way Forward
This does not de-rail our overall security roadmap. It just amends. And, luckily, we are in a good position to implement, as we have very solid software, building on excellent components and so the changes are actually not that big a project. As a side-note, we already have ramped up our security hardening effort even more for quite a while. And we continue to evaluate every aspect very much in-depth.
An important aspect of the implementation is also to make post quantum technology easy to use, which means great doc, and a great feed for AI that all users can query public AI on proper setups.
Feedback on that effort, including GitHub issues and pull requests, of course is highly appreciated.
For Those Who Want the Technical Meat
I mentioned a first PR for rsyslog. It focuses on securing transport protocols with post-quantum capable key exchange. Specifically, rsyslog adds support for hybrid TLS key exchange using X25519 together with ML-KEM-768 (formerly Kyber-768) on systems where the underlying TLS libraries already provide this capability. In practice this means the hybrid group X25519MLKEM768 on OpenSSL and GROUP-X25519-MLKEM768 on GnuTLS builds. At this stage the work concentrates on hybrid key exchange; post-quantum certificate signatures such as ML-DSA (Dilithium) are intentionally not introduced yet.
Some modern Linux distributions have already begun enabling post-quantum primitives in their crypto stacks, which makes it easier for applications like rsyslog to adopt hybrid TLS when the libraries support it. Our effort extends such movements to the application layer and gives administrators explicit control over how these capabilities are used.
Again, all suggestions for steering this effort to the best possible result are highly welcome.