The Problem with Cryptographic Registries: When Enumeration Creates Vulnerability

The digital infrastructure that underpins our modern world relies heavily on cryptographic protocols to secure communications, authenticate identities, and protect data integrity. Yet, a fundamental design choice in many of these protocols may be introducing more problems than it solves: the use of registries that map numeric or string identifiers to cryptographic algorithms and primitives.

Cryptographic registries appear everywhere in our digital ecosystem. They enumerate signature algorithms, hash functions, ciphers, key exchanges, and various encodings. From TLS and X.509 to SSH and PGP, these registries serve as directories that allow protocols to negotiate which cryptographic primitives to use during runtime communication. The IETF/IANA maintains a formal bureaucracy for managing these registries, complete with bylaws and procedures that have sparked considerable debate among protocol designers.

The fundamental problem with these registries, as argued in the article "Registries Considered Harmful," is that they encourage what's known as "cryptographic agility" - the ability to easily swap cryptographic primitives. While this might sound like a good design principle on the surface, it has become increasingly clear that this approach is a common source of protocol vulnerabilities.

When a protocol requires enumeration of supported options, it implies multiple choices are available, which introduces complexity. More critically, it necessitates runtime negotiation of cryptographic choices - a process that inherently creates opportunities for implementation errors, protocol inconsistencies, and security vulnerabilities. The negotiation process must be carefully implemented, tested, and maintained across different implementations, multiplying the potential attack surface.

Consider the TLS protocol as an example. Its extensive registry of cipher suites, signature algorithms, and key exchange methods has created a complex ecosystem where implementations must handle numerous combinations of options. This complexity has historically led to vulnerabilities such as protocol downgrade attacks, implementation errors in cipher suite negotiation, and misconfigurations that weaken security.

Abstract registries present an even more insidious problem. The IANA registry of Authenticated Encryption with Associated Data (AEAD) algorithms, for instance, suggests that protocols should be parametrizable to support any of the listed AEAD implementations. This design encourages protocols to defer critical cryptographic decisions to runtime, rather than making deliberate choices at design time.

The alternative approach, as demonstrated by the "age" encryption tool, is to select specific, well-vetted cryptographic primitives for each protocol version and stick with them. Age v1, for example, uses ChaCha20-Poly1305 for encryption, HKDF-SHA256 for key derivation, and HMAC-SHA256 for authentication. There are no runtime negotiations or identifiers next to ciphertexts - only a format version number in the header.

This approach has several advantages:

1. Reduced complexity: By eliminating runtime negotiation, protocols become simpler to implement and verify.
2. Clearer security properties: When a protocol uses specific primitives, its security properties are well-defined and easier to analyze.
3. Easier maintenance: If a cryptographic primitive needs to be replaced, the protocol can be versioned rather than patched.

The argument against registries gains strength from the modern software development landscape, where rapid updates and patches have become the norm. The industry now understands that updating software quickly is critical for security, weakening the case for runtime configuration-based mitigations. If a cryptographic primitive is found to be vulnerable, a software update that replaces it is often more practical than maintaining complex negotiation logic.

Even when multiple options seem necessary - such as supporting different key types - the author suggests avoiding registries by making the signature type a property of the key being used to verify it. This approach prevents dangerous scenarios like those found in JWT, where a signature can instruct a verifier to use an RSA public key as an HMAC secret key - a clear type confusion vulnerability.

It's important to note that the author isn't arguing against interchangeable primitives that implement well-defined APIs. Variety in cryptographic primitives is essential for innovation, competition, and specialized use cases. The issue arises when protocols attempt to support all possible combinations through runtime negotiation.

The age tool does include something resembling a registry for recipient types (X25519 and scrypt), but these have different user-visible behaviors rather than being merely internal cryptographic choices. This represents a legitimate distinction - choices that affect semantics may warrant user visibility, while internal cryptographic choices should be made by protocol designers.

This distinction highlights a broader principle: if a cryptographic choice affects semantics (like passphrase versus public key encryption), it may be appropriate to let users make the decision. However, when choices have no semantic implications (like between different hash functions or ciphers), it's the responsibility of cryptography engineers to make those decisions, as users and developers are rarely in a better position to evaluate cryptographic trade-offs.

Counter-perspectives to this argument do exist. Some cryptographic scenarios may genuinely benefit from agility, particularly in long-lived protocols where cryptographic primitives may need to be replaced over time. Additionally, registries can facilitate interoperability between different implementations and allow for gradual transitions between cryptographic primitives.

However, the risks introduced by registries often outweigh these benefits. The complexity of maintaining secure negotiation logic, the potential for misconfiguration, and the increased attack surface all contribute to a security landscape that is more fragile than necessary.

As we continue to develop the cryptographic infrastructure of the future, we should consider whether the convenience of cryptographic agility justifies its costs. The evidence suggests that in most cases, it does not. By making deliberate choices at design time and using versioning to handle necessary changes, we can build protocols that are both secure and maintainable.