CNSA 2.0 Algorithms: OpenSSL 3.5’s Q-Safe Group Selection

CNSA 2.0 Algorithms

In accordance with the NSA’s CNSA 2.0 recommendations, OpenSSL version 3.5 adds improvements to TLS(Transport Layer Security) 1.3 to give quantum-safe cryptographic algorithms priority. With these additions, servers can choose Q-safe algorithms preferentially during the TLS handshake and clients can express a preference for them.

OpenSSL uses novel configuration techniques to accomplish this without changing the TLS standard. For example, it uses a delimiter for servers to arrange algorithms by security level and a prefix character for clients to suggest key sharing.

By guaranteeing backward compatibility and reducing unnecessary network round trips, these modifications seek to enable a seamless transition to post-quantum cryptography while upholding the “prefer” requirement for Q-safe algorithms. OpenSSL is the first significant TLS library to fully implement the CNSA 2.0 preference with this version, and because of its long-term support status, it is expected to be widely adopted.

Q Safe

The Need for Quantum-Safe Cryptography and the Imminent Danger of Quantum Computers

The primary force behind this work is the potential for quantum computers to crack asymmetric cryptography schemes that are currently in use.

You can also read EQCC Gets Quantum System Two By IBM, Basque Government

• “Future quantum computers will be able to break the asymmetric cryptographic algorithms widely in use online today.”

• To preserve the security of online communication, this calls for a switch to quantum-safe (or Q-safe) cryptographic techniques.

The CNSA 2.0 mandate of the NSA as a Major Initiator

The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), released by the US National Security Agency (NSA), contains a list of authorized quantum-safe algorithms along with a schedule for their implementation. The allowed methods for TLS are ML-KEM (FIPS-203) for key agreements and ML-DSA (FIPS-204) or SPINCS+ (FIPS-205) for certificates.

According to the CNSA 2.0 mandate, systems must be set up to “prefer CNSA 2.0 algorithms” during the initial transition period and to “accept only CNSA 2.0 algorithms” as products advance. The goal of this two-phase strategy is a smooth and gradual transition.

The TLS Standard’s “Preference” Implementation Challenge

Clients and servers can choose post quantum cryptographic algorithms freely to the TLS standard (RFC 8446), which does not require a particular preference mechanism. “Such a choice is not required by the TLS standard. The TLS standard gives both the client and the server a great deal of flexibility in selecting their preferred encryption methods.

Therefore, a method to set up TLS connections to allow preference for CNSA 2.0 algorithms is desperately needed. This calls for figuring out how to implement the idea of favoring Q-safe algorithms without changing the TLS protocol itself.

The Solution: OpenSSL v3.5 Improving Configuration Features

Since changing the TLS standard itself was not an option, the developers concentrated on improving OpenSSL’s configuration capabilities to overcome the obstacle. Allowing OpenSSL-using apps (like cURL, HAproxy, and Nginx) to take advantage of the new preference options without needing to modify their code was the aim.

You can also read SES and SpeQtral Sign MoU Quantum-Secure Communications

Client-Side Solution: Using a Prefix Character to Indicate Preference

With OpenSSL v3.5, clients can express their preference for Q-safe algorithms by placing a special prefix character (”) before the algorithm name in the list of acceptable algorithms that is separated by colons. For instance, in the ClientHello message, “ML_KEM-1024:ML-KEM-512:*x25519” instructs the client to produce and send key shares for ML-KEM-1024 and x25519, indicating support for four algorithms.

A client can only send a maximum of four key shares, which can be changed using a build option, in order to avoid network overload caused by the larger size of Q-safe key shares. A fully Q-safe algorithm, a hybrid algorithm, a legacy algorithm, and a spare are all intended to be supported under this architecture.

If no ‘*’ prefix is specified, a single key share is automatically added for the first algorithm in the list to preserve backward compatibility.

Server-Side Solution: Establishing Preference Hierarchy Algorithm Tuples

By providing a new method of defining the server’s preferred algorithm order using tuples delimited by the ‘/’ character within the colon-separated list of algorithms, the server-side approach overcomes TLS’s absence of a native “preference” mechanism.

This enables the server to choose algorithms using a three-level priority system:

• Processing tuples from left to right has the highest priority.
• Overlap with client-provided key sharing within a tuple is the second priority.
• The third priority is to overlap within a tuple with other client-supported methods (without key shares).

An illustration would be “ML-KEM-768 / X25519MLKEM768

x25519 / SecP256r1MLKEM768″ defines three tuples. Within each tuple, the server will first priorities algorithms in the earlier tuples, then take into account the availability of key shares, and lastly, general support.

In spite of the possibility of a HelloRetryRequest (HRR) penalty, the text demonstrates how this technique guarantees that the server favors Q-safe algorithms even in the presence of a legacy algorithm with an easily accessible key share: “However, the prefer mandate of CNSA 2.0 enforces higher priority to the use of Q-safe algorithms, even if that comes at the cost of a round-trip penalty which is completely achieved using the new specification syntax.”

Preserving Backward Compatibility and Reducing the Effect on Current Systems

Ensuring complete backward compatibility to facilitate a seamless transition was a key design element. Existing applications can use the new configuration syntax without needing to change their code. To prevent affecting other features, the OpenSSL codebase modifications were meticulously applied in “a few pinpointed locations” throughout the vast codebase.

Extra Considerations for Implementation

A “?” prefix was added to enable ignoring unknown algorithm names, handle pseudo-algorithm names like “DEFAULT,” and permit the use of the same specification string on both the client and server sides (requiring the client to ignore server-specific delimiters and the server to ignore client-specific prefixes).

OpenSSL v3.5’s Collaborative Development and Significance

The OpenSSL maintainer team and other specialists were consulted and worked with extensively during the development process. The “excellent interactions” during the development are highlighted in the text.

A noteworthy accomplishment is OpenSSL v3.5, which is described as “the first TLS library to fully adhere to the CNSA 2.0 mandate to prefer Q-safe algorithms.” It is anticipated that Linux distributions would adopt OpenSSL v3.5 more broadly due to its Long-Term Support (LTS) status, which will make these new quantum-safe communication features widely available.

Conclusion

In order to protect online communication from the potential threat of quantum computers, OpenSSL v3.5’s incorporation of the Q-safe algorithm preference is essential. The developers have met the NSA’s CNSA 2.0 mandate by ingeniously expanding OpenSSL’s current configuration facilities without necessitating major code changes in OpenSSL-reliant apps or changes to the TLS standard itself.

You can also read Hot Schrödinger Cat States: High-Temp Quantum Superpositions

A progressive shift to a more secure digital future is made possible by the client-side prefix and server-side tuple-based preference systems, which offer a workable and backward-compatible method of giving quantum-resistant cryptography priority. OpenSSL v3.5’s LTS status guarantees its broad use, increasing accessibility to quantum-safe communication on a variety of systems.

FAQs