Why Hardcoding Algorithms in Your Codebase Is a Liability

Most developers call cryptographic libraries directly from their code, importing the required functions from Bouncy Castle or other cryptographic libraries and baking the cryptography into the application logic. For years, this was fine as the algorithms and configurations considered secure and best practice remained largely static.

With the upcoming arrival of large-scale quantum computing, this practice becomes a significant liability. Migrating to post-quantum algorithms will require manually changing each of these direct invocations of cryptographic libraries. This may not be a one-time change either, if post-quantum algorithms are broken or standards evolve to recommend new configuration settings.

Why Developers Hardcode Cryptography

The practice of hardcoding cryptographic calls is common because it's easy. AES, RSA, SHA-256, and other algorithms have been in use for years with little or no changes to their usage.

When developers are under pressure, a hardcoded call makes more sense than setting up a cryptographic abstraction layer, especially when doing so hurts nothing. However, the shrinking time until Q-Day changes the risk calculus.

Where Hardcoding Cryptography Goes Wrong

Hardcoded cryptographic code is only a problem when that cryptographic code needs to change. Some common reasons for these code updates include:

Quantum Migration: The change to post-quantum algorithms is the main reason why organizations adopt crypto-agility. Organizations are expected to migrate away from RSA and elliptic curve cryptography (ECC) by 2031, making it necessary to swap out these algorithms for post-quantum alternatives.
Vulnerable Libraries: Cryptographic libraries can contain logical or implementation errors that undermine the security of the algorithms and mandate updates. For example, CVE-2020-28052 was a vulnerability in Bouncy Castle that allowed Bcrypt authentication bypasses.
Hybrid Implementations: In the near term, a post-quantum migration involves implementing hybrid algorithms, combining a classical algorithm like RSA with a post-quantum counterpart. This addresses the two main risks to cryptographic code: that quantum computers will break classical algorithms and that post-quantum versions may contain currently unknown weaknesses that undermine their security.
Evolving Post-Quantum Standards: While NIST has standardized post-quantum algorithms for key establishment and digital signatures, these standards can change. Additionally, new standards are anticipated, such as FIPS 206, standardizing FN-DSA. Evolving and new standards can require additional changes to the code.

In some cases, addressing hardcoded cryptography is an easy fix if the new algorithm or configuration can slot right into place. However, other changes can have cascading effects. For example, the switch to post-quantum digital signature algorithms dramatically increases public key and signature lengths (RSA-3072 ≈ few hundred bytes vs. ML-DSA's 2,420-byte signature), impacting the variables used to store these values and memory management within an application.

The Fix: Cryptographic APIs

Hardcoding cryptography is problematic because it mixes application logic and cryptographic code. This means that every change to the cryptography requires modifying the application code that uses it.

The solution is to implement cryptographic APIs, introducing an abstraction layer between the application code and the cryptographic algorithms it uses. When implementing these abstractions, changes to the underlying cryptography only affect the API backend, not every application that relies upon it.

By centralizing cryptographic code in APIs, an organization enhances its crypto-agility and dramatically decreases the cost and complexity associated with updates. However, these interfaces need to be carefully designed and implemented to avoid dangerous assumptions. For example, changes in key and signature lengths for digital signature algorithms could still break applications relying on a crypto API if these lengths are hardcoded within the application code calling the API.

The Warning Signs of Poor Crypto-Agility

Hardcoded cryptography is one of the main reasons why an organization suffers from poor crypto-agility. Some of the warning signs include:

Cryptographic library imports and calls scattered throughout the codebase
Fixed-size buffers for public/private keys, digital signatures, and ciphertexts
Lack of an internal cryptographic module or API

Ideally, all of these should be addressed within a cryptographic bill of materials (CBOM). If an organization doesn't have an up-to-date, complete CBOM, that's the first step to fixing the problem.

Addressing Common Objections to Crypto-Agility

Implementing cryptographic APIs can seem like unnecessary additional overhead for a fairly rare event. Some common objections to implementing crypto-agility include:

"It'll be addressed during migration": For legacy applications with hardcoded cryptography, the organization's quantum migration might be a logical time to switch to crypto APIs. Failing to make this change and continuing to hardcode cryptography in new code can increase costs in the future, since every cryptographic update requires finding and updating all uses of the cryptography within application code.
"Our library gets patched automatically": For minor changes to a cryptographic algorithm or a swap between similar algorithms, automatic library updates might fix the problem without the need to change application code. However, the same isn't true for quantum migration. Organizations will need to implement hybrid cryptography, followed by solely post-quantum cryptography over the next few years, and new algorithms have different key lengths and output sizes than their classical counterparts.
"Abstraction adds complexity and introduces risk": When it comes to cryptography, a broken algorithm is worse than no algorithm at all since it just creates a false sense of security. Implementing a crypto API allows an organization to centralize its cryptographic code, ensuring that no application is overlooked when performing critical updates.

Implementing Crypto-Agile Principles

Crypto-agility is best practice for any application that uses cryptography. It not only streamlines quantum migration but also enables an organization to rapidly respond to vulnerabilities identified in crucial cryptographic libraries.

The first step to achieving crypto-agility is gaining visibility into the organization's use of cryptography. A comprehensive, up-to-date CBOM maps out all cryptography used by the business and the current state of the migration to crypto-agile code.

FAQs

Isn't using a well-known library like Bouncy Castle safe enough on its own?

No, even well-known libraries like Bouncy Castle can contain vulnerable code that requires updates. This also won't help with quantum migration, where the organization needs to completely change the algorithms that it uses.

How much work does adding a crypto API actually take?

The workload depends on the state of the organization's codebase, including the algorithms used and how scattered existing calls are. Writing the API itself largely requires just moving the crypto calls from the application code to the API backend. However, updating the application code may require reworking buffers, etc. to accommodate variable-length keys, signatures, and ciphertexts.

Does this matter if we're not doing PQC migration yet?

Quantum migration is the most well-known reason that organizations implement crypto-agility. However, making the change now helps to address the other drivers of cryptographic code updates, such as a broken cryptographic algorithm or a vulnerability detected in a core cryptographic library.