Our Contribution to The White House PQC Roundtable – Part 2: Preparing for Post-Quantum Cryptography

Share this post

Part 2: Preparing for Post-Quantum Cryptography

On Jan. 26, 2024, Quantum Xchange joined the White House Office of Management and Budget (OMB), the White House Office of Science and Technology Policy (OSTP), and other members of the intergovernmental PQC Migration Working Group to discuss, debate and prepare formal guidance for government agencies as they begin their efforts to replace legacy encryption with post-quantum cryptography (PQC).

In a three-part blog series, we share Quantum Xchange’s responses to the pre-event questionnaire all PQC Roundtable distinguished guests were asked to complete.

Q: How will networks need to be re-architected to prepare for PQC migration?

Preparing networks for PQC migration involves a strategic approach with both current initiatives and plans for the next 3-5 years, along with an ongoing strategy:

Current/Immediate Initiatives

Enhanced Key Generation: Upgrading existing hardware encryptors by implementing external entropy sources. This will enhance the strength of encryption and authentication processes.
Out-of-Band Key Exchange: Adding a layer of out-of-band symmetric key exchange to existing network hardware. This step creates a separation between the processes of data transmission and key exchange, enhancing security.

In the Next 3-5 Years

PQC-Ready Encryptors: Transitioning to encryptors that are equipped with PQC capabilities. The focus should be on network segments where the data is highly sensitive and has long-term value, necessitating robust protection against future quantum threats.

Ongoing Strategy

Network Hardware Agility: Ensuring that network hardware maintains cryptographic agility. This involves the capacity to seamlessly update existing cryptographic algorithms and integrate new ones as PQC standards evolve. This strategy is essential for keeping up with the rapidly changing landscape of cryptographic threats and solutions.

Additionally, a significant impact is expected from the integration of the NIST-standardized PQC algorithms into new protocols like TLS 1.4 or TLS 2.0. Adopting these standards will facilitate a smooth and seamless transition to PQC for web services and browsers.

This adoption will cover most online traffic immediately, without the need for specialized hardware or extensive architectural changes. This approach is seen as the most efficient and cost-effective way to broadly implement PQC, providing widespread protection against quantum threats with minimal disruption to current network structures.

Q: Which mission capabilities or functions should agencies prioritize for testing of PQC algorithms?

The focus for testing PQC algorithms should be on implementing and evaluating crypto diversification and redundancy, as these are key to building resiliency in cryptographic systems. The rationale for this approach is multifaceted:

Redundant Encryption: Agencies should test for redundant encryption where at least two different algorithms are used to encrypt all traffic. This strategy enhances security by not relying on a single encryption method, thereby reducing the risk of total system compromise if one algorithm is defeated.
Support for Multiple Approaches: The industry needs to support the simultaneous use of multiple cryptographic approaches. This is based on the understanding that cryptographic methods will evolve over time, with new methods emerging and existing ones potentially becoming obsolete.
Combination of Asymmetric and Symmetric Key Technology: Agencies should mix asymmetric key technology with symmetric key technology. This combination leverages the strengths of both types of cryptography for enhanced security.
Out-of-Band Key Transmission: Transmitting keys through out-of-band channels is another area to prioritize for testing. This method adds an extra layer of security in the key exchange process.
Development of Metrics and Benchmarks: There is a need to develop agreed-upon metrics and industry-wide benchmarks to measure the level of diversification in crypto strategies. These metrics will help in assessing the effectiveness and robustness of the cryptographic approaches being tested.

Overall, the focus should be on creating a versatile and robust cryptographic infrastructure that can adapt to changing threats and technologies. By prioritizing these areas for testing PQC algorithms, agencies can ensure that their cryptographic systems are not only secure against current threats but are also prepared for future challenges in the realm of cryptography.

Q: In what cases will agencies need to acquire new hardware as part of their PQC migration?

The need for new hardware in the context of PQC migration varies based on the type of hardware and its current capabilities:

Desktop Workstations and Server/Datacenter/Cloud Hardware: These will generally operate seamlessly with updated PQC standards through TLS and software upgrades, eliminating the need for new hardware. However, current Trusted Platform Modules (TPMs) are not equipped to handle PQC algorithms and key storage.

Despite this limitation, endpoints will still be able to use software-based PQC algorithms as TPMs are not mandatory for this function.

Network Infrastructure: Most network infrastructure elements, such as routers, switches, and WiFi access points, will become quantum-safe primarily through software updates. However, there is an exception for older hardware that might not support the added storage and processing requirements of PQC.

Some of this older infrastructure may not be capable of running the updated operating systems that include PQC implementations, necessitating hardware upgrades.

Internet of Things (IoT) Technology: IoT devices are likely to face challenges in adopting PQC. In some cases, it will not be straightforward to integrate legacy communications with quantum-safe tunnels.

For example, it’s impractical to front-end each device in a network of IoT security cameras with a PQC proxy. However, in many scenarios where IoT is deployed, the facility or network requirements might not consider cryptographic algorithms as the weakest link, possibly reducing the urgency for updates.

While desktop workstations, servers, and most network infrastructure can become quantum-safe through software updates, older network hardware and certain IoT technologies may require new hardware for PQC migration. The decision to acquire new hardware will depend on the specific capabilities and limitations of the existing infrastructure, as well as the security requirements and the potential vulnerability of the hardware to quantum threats.

Q: Where may agencies see performance impacts as a result of their PQC migration?

Agencies are unlikely to experience significant performance impacts from PQC migration in most areas, with the potential exception of legacy IoT devices. We don’t believe the use of larger key sizes (such as 1Mb keys) and more frequent key exchanges associated with PQC will significantly burden modern processors and networks.

The rationale behind this assertion is that the processing power available even in average smartwatches today, along with the bandwidth exceeding gigabits in most homes, are more than sufficient to handle the demands of PQC.

In the case of legacy IoT devices, if they are capable of being upgraded to support PQC, there might be some performance impacts due to their typically limited processing power and storage capacity. However, in general, the current state of technology in terms of processing capabilities and network bandwidth is seen as well-equipped to handle the requirements of PQC without major performance degradation.

This perspective suggests that concerns about performance impacts due to PQC migration may be overstated, especially considering the rapid advancements in technology and the increasing availability of high processing power and bandwidth. The primary area of focus regarding performance issues should be on older, less capable IoT devices, where upgrades to support PQC might be more challenging.

Don’t miss Part 1 and Part 3 of this three-part series.
Explore Solutions with CipherInsights