Modern digital security relies on public-key encryption (like RSA and ECC) to protect global data. The future arrival of a Cryptographically Relevant Quantum Computer (CRQC) will completely break these mathematical foundations. To counter this, organizations must migrate to Post-Quantum Cryptography (PQC) — new, math-based algorithms deployed via standard software that quantum computers cannot exploit.
The PQC migration requires to protect data “at rest” (i.e. static data stored on physical drives, databases, cloud storage, or backups) and “in transit” (i.e. data transmitted on computer networks, including HTTPs and VPNs). In the latter case quantum computers running Shor’s Algorithm will easily break these keys hence attackers are currently executing “Harvest Now, Decrypt Later” (HNDL) attacks — stealing encrypted network traffic today to decrypt it the moment a quantum computer becomes available. In order to mitigate this risk, the National Institute of Standards and Technology (NIST) has finalized its first official Post-Quantum Cryptography (PQC) standards (FIPS 203, 204, 205) to fully discontinue legacy public-key algorithms by 2035.
The work described below on this post comes from months of bootstrapping QubitOwl, our partner startup on which we as taking part as core technology providers in building a comprehensive PQC posture analysis solution. For a complete PQC tool we suggest you to have a look at the QubitOwl CONTINUUM tool that features a complete PQC analysis including both “at rest” and “in transit” tools.
At ntop we analyze network traffic hence we focus on PQC in transit. In particular we need to analyze encrypted traffic protocols such as:
- TLS (Transport Layer Security)
- QUIC (Quick UDP Internet Connections)
- SSH (Secure Shell)
- IPSEC (IKE – Internet Key Exchange)
These protocols are used for transmitting data in a secure fashion by exchanging encrypted data. Unfortunately with the advent of PQC, network administrators need to identify hosts using non-PQC compliant versions of the above protocols and upgrade them. In order to ease the identification of these obsolete assets, we have enhanced ntop tools (ntopng Enterprise, nProbe, cento) using nDPI Pro in order to spot non-PQC compliant communications and report then.
In the above picture you can see how ntopng has detected a SSH non-PQC compliant communication, and identify the weakness side (the client is PQC ready, whereas the server is using an obsolete SSH version). As you can see detailed protocol information is reported in order to ease migration and identify the exact software version responsible fopr the issue.
If you store flows on ClickHouse you can easily find all non-PQC compliant with a matter of clicks.
At any time you can enable/disable the PQC from the behavioral check page.
If you want to know what network assets are not PQC-ready you can do it in a matter of clicks.
Please remember that PQC analysis is based on nDPI, hence you can use it only if you monitor packets including nProbe/Cento that monitor packets and send flows to ntopng, but not if you collect flows sent by a router (NetFlow/IPFIX/sFlow).
Enjoy !