The US standards institute recently completed the third round of the Post Quantum Crypto (PQC) standardization process. This milestone was long-awaited, and even though we are one step closer to a PQC standard, the race is not over yet.
PQC is a new generation of cryptographic algorithms that can withstand brute-forcing attacks executed with future quantum computers. While these machines do not yet exist, it is very relevant to prepare for their advent. Many experts expect quantum computing to be practical before the current decade is out. Some cryptographic applications do require a long time of secrecy, and therefore it is not a luxury to be prepared.
But, there is another reason to be working on PQC standardization. Building trust in new cryptographic algorithms takes a lot of time. AES, the dominant symmetric algorithm, was selected in the year 2000 after an exciting process where scientists around the world made proposals and scrutinized the various candidates. Even while NIST and the crypto community were enthusiastic about their choice, it took a decade to replace legacy technology. This was partially because users wanted to see whether the first applications would hold up against real-life threats, where adversaries had something to gain by investing in attacks. Another reason was the cost of the upgrade, with all the dependencies in (globally) connected systems.
With the completion of the third round, NIST selected a preferred signature algorithm, and a preferred key encryption algorithm. Since there is still doubt about the new technology, two alternative candidates have been chosen, and additionally, the fourth round was started to closer evaluate four more candidates. Surprisingly, two new attacks emerged in a very short time that effectively terminated SIKE, one of those four candidates. This incident proves that a diligent and iterative process is beneficial, even though the slow pace is painful.
Developers working on crypto products that need to support long-time secrecy may now find the time right to implement and deliver their implementations, but users should remain a little cautious, as more surprising weaknesses may still surface.
If you have any questions, contact us at inforequest@riscure.com.