Post-quantum cryptography in NXLog Agent: Post-quantum readiness for Q-Day

The mechanics are straightforward. An adversary sits on a network — a hostile ISP, a compromised cloud tenant, a tapped fiber run — and records encrypted traffic as it passes. They cannot read it. Today’s TLS is not breakable with classical computers. So they do not try. They archive the ciphertext and wait.

At some point in the next decade, a cryptographically relevant quantum computer will exist. Most credible forecasts place this between 2030 and 2035; the U.S. NSA, CISA, and NIST treat it as inevitable enough to mandate migration timelines. On that day, every RSA, ECDH, and ECDSA-protected message ever recorded becomes readable. The conversation that mattered most is now the one the attacker has had on their shelf the longest.

And that is the optimistic version. The "Q-Day is comfortably twenty years away" forecast is starting to look about as durable as Bill Gates' supposed claim that 640 KB of RAM would be enough for anyone. Every twelve months brings a new milestone — qubit counts climbing, error correction improving, vendors hitting roadmap targets earlier than they themselves expected. The honest answer is that nobody knows. The unhonest answer is to assume you have until 2035. If the data on your network needs to stay confidential past 2030, the time to act on that is now, regardless of when Q-Day actually lands. And AI can accelerate everything.

In August 2024, NIST published the first three finalized post-quantum standards. Two of them are what concern us here:

A third standard, FIPS 205 (SLH-DSA), provides a conservative hash-based signature alternative. ML-DSA comes in three parameter sets that map to NIST security levels:

The pieces to put these standards into TLS 1.3 in production are now in place. Major cloud providers have started. Cloudflare and AWS run PQC-enabled services in production today. Google is piloting hybrid TLS configurations. Microsoft has work underway in Azure, but Windows itself — the Schannel TLS stack in Windows 11 and Windows Server 2022 — does not yet support PQC natively, which means on Windows the practical path runs through OpenSSL.

That is the path NXLog Agent already supports. OpenSSL 3.5 added native ML-KEM, ML-DSA, and SLH-DSA, including the TLS 1.3 hybrid key exchange group X25519MLKEM768. NXLog Agent’s TLS modules — im_ssl and om_ssl — use OpenSSL underneath. On a host with OpenSSL 3.5 or later, NXLog Agent can negotiate post-quantum TLS today. The rest of this post shows that.

The setup is a single RHEL 9 host running NXLog Agent 6.13 (the generic build) against OpenSSL 3.5.1. Both endpoints — sender and receiver — live on the same agent instance so the handshake is reproducible.

The agent config drives synthetic events from im_testgen through om_ssl over TLS 1.3, with im_ssl listening on the receiving side and routing to om_null. Both sides require mutual TLS:

Nothing in the agent config above mentions PQC explicitly. That is the point. NXLog Agent does not need to know that the certificates it loads use a post-quantum signature algorithm, or that the key exchange group is hybrid. OpenSSL handles both, and NXLog Agent inherits the capability.

The interesting work happens before NXLog Agent starts: generating a CA and two leaf certificates whose keys and signatures are ML-DSA, not RSA or ECDSA. With OpenSSL 3.5, this is a one-flag change — -algorithm ML-DSA-65 replaces -algorithm RSA or -algorithm EC. The CA key:

The server and client certificates are signed by this CA using the same algorithm. Each openssl req generates an ML-DSA-65 key; each openssl ca issues a certificate signed with ML-DSA-65. The full sequence — including the openssl-pqc.cnf that ties everything together — is in the test report. What matters here is what comes out the other side:

The certificate looks like any other X.509 certificate to anything that does not care about the algorithm details. It has a Subject, an Issuer, a SAN, and an Extended Key Usage. The difference is in two places: Public Key Algorithm: ML-DSA-65, and the signature on the certificate is itself ML-DSA-65. With these dropped into the agent’s certificate directory:

Restart the agent instance, and the two TLS endpoints inside it handshake successfully on the first attempt:

The handshake completes over TLS 1.3 with the expected AES-256-GCM-SHA384 cipher. The agent’s own log does not surface which signature algorithm or which key-exchange group was negotiated — those are TLS-layer details that im_ssl does not currently expose. To confirm the post-quantum primitives actually got used, we run the same handshake one more time with openssl s_client as the client.

OpenSSL’s test client lets us request specific signature algorithms and key-exchange groups, and reports exactly what was negotiated. The flags that matter:

The -sigalgs list offers ML-DSA-65 first, with ECDSA as a fallback. The -groups list offers the hybrid X25519MLKEM768 group first, with classical curves as fallbacks. If the agent did not support PQC, the connection would still succeed using the fallbacks — which is exactly the kind of silent regression you want a test to catch.

It does not fall back. The agent picks the post-quantum options on both ends:

Three lines from that output are the whole result:

And the underlying record protection remains the TLS 1.3 standard cipher, AES-256-GCM-SHA384, which is already considered quantum-resistant for the bulk-data phase. The post-quantum work is concentrated where it matters: the authentication that proves the peers are who they say they are, and the key exchange that establishes the shared secret.

The result is that any agent instance running on a host with OpenSSL 3.5 or later is PQC-ready today — it can already transport its data over a post-quantum mTLS channel, end to end, using NIST-standardized algorithms, without changes to NXLog Agent itself. On Linux this is available now. On Windows and MacOS, it depends on the Schannel roadmap, but agents that link against OpenSSL get there immediately.

A few honest caveats:

Q-Day is a future event, and the exact date is genuinely uncertain. What is not uncertain is the asymmetry: the cost of moving your traffic to post-quantum TLS in 2026 is a configuration change. The cost of moving it in 2034 is the same change, plus eight years of data you sent in the clear from the attacker’s perspective.

If the data NXLog Agent moves for you matters in 2040, it needs PQC in 2026. NXLog Agent supports it today. The standards are final. The OpenSSL implementation is shipping. The only remaining step is to issue the certificates and turn it on.

Find full TLS configuration details in Transfer data over the network with TLS/SSL. If you want help planning the post-quantum readiness path for your existing NXLog deployment — auditing where classical TLS is still in use, sizing the impact of PQC-ready certificates, or working out a phased rollout — reach out to us through the links below.