Last month, while examining the security of user data in a manufacturing ERP, I started thinking about the potential future weaknesses of our current encryption standards. The emergence of quantum computers, in particular, with their potential to break traditional asymmetric encryption algorithms, is no longer just science fiction; it has become a concrete security risk that we need to address today. This situation also brings with it the attack scenario known as “Harvest Now, Decrypt Later,” which is one of the most unsettling scenarios for me.
In this post, I will explain, based on my own experiences, why Post-Quantum Cryptography (PQC) should be on our agenda starting today, how our current encryption methods are under threat, and what we need to consider during this transition. This topic is not just a theoretical discussion; it directly concerns anyone protecting long-lived and sensitive data.
How Do Quantum Computers Threaten Our Current Encryption?
Quantum computers have the potential to perform certain calculations much faster than classical computers. This means that, with specific algorithms like Shor’s algorithm, they can efficiently solve the mathematical problems that form the basis of most of today’s asymmetric encryption systems (e.g., factoring large numbers or the elliptic curve discrete logarithm problem). Widely used algorithms like RSA and ECC (Elliptic Curve Cryptography) will be vulnerable to this capability.
This threat is critical, especially for data that needs to be protected in the long term. For example, supply chain information, financial records, or customer data stored in a manufacturing ERP must maintain their confidentiality for decades. If an attacker obtains this encrypted data today and waits for a quantum computer to emerge in the future, that data could become decryptable, even if it was encrypted in the past. This creates a security vulnerability that affects not only today but also the future.
What Does NIST’s Post-Quantum Cryptography (PQC) Standardization Process Mean?
Recognizing this potential threat, the U.S. National Institute of Standards and Technology (NIST) has been conducting a comprehensive process to standardize post-quantum cryptographic algorithms since 2016. This process aims to evaluate algorithms proposed by cryptography experts worldwide, eliminate weak ones, and identify strong and practical solutions. This is not a process we can simply dismiss; it forms the foundation of our future digital security.
NIST, after several rounds of evaluation, has selected various PQC algorithms for different use cases. For example, algorithms like ML-KEM (formerly CRYSTALS-KYBER) for key exchange and ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures are prominent. These standardization efforts provide a clear roadmap for software developers, system architects, and security professionals on which algorithms to use. For me, this is an important step that reduces uncertainty and makes it easier for us to act.
NIST’s process not only selects algorithms but also deeply examines their performance, security features, and potential for integration with existing systems. These detailed analyses provide us with the necessary information to design more robust and future-ready systems.
What is the ‘Harvest Now, Decrypt Later’ (HNDL) Attack and Why is it Critical?
The “Harvest Now, Decrypt Later” (HNDL) attack poses a significant threat even in this period when quantum computers are not yet fully operational. In this scenario, malicious actors collect and store sensitive data (e.g., VPN traffic, database passwords, personal information) that is transmitted or stored encrypted today. When quantum computers become commercially accessible, these attackers will be able to easily decrypt all the data they have collected.
This type of attack is lethal, especially for data that needs to remain confidential for a long time. Information such as records of financial transactions on a bank’s internal platform, patent information in a manufacturing company’s ERP, or user data I keep in my side product, if disclosed even 5-10 years later, can cause serious damage. Therefore, delaying the transition to post-quantum cryptography effectively means inviting a future security disaster.
This situation requires us to rethink data lifecycles and encryption strategies, especially when designing system architectures. We must take steps by calculating not only today’s risks but also the risks of the next 10-20 years.
What Should We Do for PQC Transition Today?
The transition to PQC will be a major transformation, and this process will affect many layers in our existing infrastructures. As I see it, there are several important steps that need to be taken now for this transformation. First, we must integrate the concept of “crypto-agility” into our systems. This means the ability to easily change and update encryption algorithms.
In existing systems, encryption algorithms are often deeply embedded in the code, making changes difficult. This structure needs to be moved to an architecture where algorithms are modularized and can be dynamically changed via configuration files or APIs. In a manufacturing ERP, this could encompass everything from TLS configuration to database encryption, user authentication mechanisms, and message queues.
Secondly, we should consider using PQC algorithms in “hybrid mode” alongside existing classical algorithms. This approach provides both quantum resistance and allows us to continue benefiting from the proven reliability of classical algorithms during this transition period when quantum computers are not yet fully developed. This is a logical strategy to balance risks and make a gradual transition. For example, when establishing a VPN connection, we could use both RSA/ECC-based and ML-KEM-based key exchange simultaneously.
# Example of a hybrid TLS configuration (pseudo-code)
# Real implementations are usually done at the TLS library and protocol level.
def negotiate_hybrid_tls(client_hello_msg):
# Check the algorithms supported by the client
supported_ciphers = client_hello_msg.get("supported_ciphers")
# Look for a pair that supports both classical and PQC algorithms
if "TLS_AES_256_GCM_SHA384_MLKEM" in supported_ciphers and \
"TLS_AES_256_GCM_SHA384_RSA" in supported_ciphers:
# Perform hybrid key exchange
# Create a shared secret using both RSA/ECC and ML-KEM keys
# This requires both algorithms to be broken
classic_shared_secret = perform_rsa_key_exchange()
pqc_shared_secret = perform_mlkem_key_exchange()
final_shared_secret = combine_secrets(classic_shared_secret, pqc_shared_secret)
return final_shared_secret
# If only classical or PQC is supported, perform the relevant key exchange
elif "TLS_AES_256_GCM_SHA384_RSA" in supported_ciphers:
return perform_rsa_key_exchange()
elif "TLS_AES_256_GCM_SHA384_MLKEM" in supported_ciphers:
return perform_mlkem_key_exchange()
else:
raise ValueError("No compatible cipher suite found.")
# This pseudo-code is simplified to explain the concept.
# A real TLS implementation is much more complex and managed by libraries like OpenSSL.Such a code example can be a good starting point to illustrate the principle. However, changing the encryption infrastructure of an existing system requires careful planning and testing.
What Are the Challenges in PQC Integration?
While the transition to PQC may seem simple in theory, it presents significant practical challenges. First, there’s the performance cost of PQC algorithms. Some PQC algorithms may have larger key sizes or slower computation times compared to existing RSA or ECC algorithms. This can cause a noticeable slowdown, especially in systems requiring high performance (e.g., web servers or real-time data streams). For a service running behind an Nginx reverse proxy, these delays can directly impact the end-user experience.
I observed such a performance drop even with a simpler cryptographic change in the backend of my own side product. When key sizes and signature sizes increase, network traffic rises, and CPU load increases. This may require careful optimizations not only at the software layer but also at the network layer (e.g., MTU/MSS adjustments).
The second challenge is backward compatibility. Existing systems and devices may not support PQC algorithms. This will require a gradual transition and compatibility modes. For example, a mobile application (Android or iOS) should be able to communicate with old APIs while also connecting to a new PQC-enabled API. This means a complex management and development process on both the client and server sides.
Thirdly, the standardization process is still ongoing, and algorithms may change over time, or better alternatives may emerge. This creates a need for continuous monitoring and updating. If you don’t make your system crypto-agile, you could face significant refactoring costs with every new standard.
What Am I Considering for PQC in My Own Systems?
I have kept PQC on my agenda for a long time in my own projects and the environments I work in. For one, data sensitivity and longevity are the most important criteria for me. If data needs to remain confidential for more than 10 years, I must make its encryption PQC-compliant. This applies especially to critical trade secrets kept in a manufacturing ERP or sensitive data processed in my own financial calculators.
At the application layer, I try to abstract encryption APIs as much as possible. That is, instead of embedding encryption algorithms directly into the business logic, I manage these operations through a separate module or service. This way, when PQC algorithms are finalized by NIST or a new algorithm emerges, I can transition without affecting the entire application by simply updating this module. This reminds me of the need for flexibility I experienced when updating kernel module blacklist configurations in an old project; when changes are made centrally and modularly, the work becomes much easier.
At the network layer, I am closely monitoring VPN topologies and TLS terminations at corporate gateways. I check whether current hardware and software offer PQC support. Although not yet widespread, I aim to transition to hybrid TLS configurations as these hardware and software support PQC over time. This will not only be a config change but also require observing the performance impacts on network devices.
Finally, I plan to expand security tests in my Continuous Integration/Continuous Deployment (CI/CD) pipelines to include PQC compatibility. When I integrate new algorithms, I should be able to automatically test their performance and security features. When used with a deployment strategy like blue-green or canary deployment, this will make PQC transitions much safer and more controlled.
Conclusion: Waiting is Not an Option
Post-quantum cryptography is no longer a topic we can “look at in the future.” “Harvest Now, Decrypt Later” attacks directly threaten the future security of the data we encrypt today. Therefore, we must be proactive and prepare our systems for PQC now.
While NIST’s standardization efforts provide us with a roadmap, the primary responsibility lies with us, the developers and system architects. Embracing the principle of crypto-agility, implementing hybrid transition strategies, and adapting our systems to this major transformation are the most critical steps for our future digital security. Let’s remember that this change is not just a technology upgrade but also a commitment to ensuring long-term data privacy and integrity.