Software engineers learned the wrong lesson in 2014. From software defects like Heartbleed to protocol failures like POODLE, over a half-dozen major vulnerabilities in cryptographic implementations, often around protocol negotiation, led to one consensus conclusion: crypto-agility was dangerous. One good protocol, backed by a reliable algorithm, ought to be sufficient.
Unfortunately, such a perfect defense doesn’t exist. The impending arrival of cryptographically relevant quantum computers (CRQCs) running Shor’s algorithm and the rapid, AI-accelerated evolution of automated cryptanalysis targeting asymmetric key exchange are combining to target the underpinnings of modern encrypted networking architectures, with no relevant safe harbor in sight.
While symmetric key algorithms (like AES) remain resistant to direct attacks, adversaries have two distinct avenues of attack today. The first is Harvest Now, Decrypt Later. Adversaries merely need to capture the entire contents of an encrypted session, keeping it (potentially for years) until CRQCs are capable of decrypting the initial key exchange. The second attack relies on using AI cryptanalysts and vulnerability researchers to rapidly target implementation flaws in communications software, exploiting defects to extract keys and messages directly.
A perfect implementation–one rooted in strong, scalable authentication; a key exchange with perfect forward secrecy; and a channel with a stable symmetric algorithm for encryption–would obviously be the first choice for any hardware or software. Sadly, such an implementation does not exist today, and even if it were within our grasp, a developer would need to ensure a completely bug-free implementation to avoid needing to upgrade in the future.
Instead, developers face a set of tradeoffs. Hard-coding cryptographic protocols may make downgrade attacks infeasible, but at the cost of making upgrades require such expensive steps as to make upgrades all but impossible. Key exchange and authentication can be done over increasingly complex side channels, relying on additional infrastructure just to create marginal secrecy improvements, whilst exposing the stability of communications channels to the availability of that third party infrastructure.
Or developers can hear the nuance in most cryptographers’ calls for less crypto-agility: implementing the ability to seamlessly upgrade in-place, while quickly deprecating primitives that are no longer safe for use. It was not crypto-agility that was at fault a decade ago. It was the overly tolerant support for deprecated algorithms, and the rapid implementation of speculative capabilities, that confused a lackadaisical cryptographic landscape for one that could upgrade with agility.
