Blog

OpenSSL 3.1.2: FIPS 140-3 Validated

FIPS 140-3 Logo

The OpenSSL Corporation is pleased to announce that OpenSSL version 3.1.2 has achieved FIPS 140-3 validation, signifying its compliance with the rigorous cryptographic module security requirements set forth by the National Institute of Standards and Technology (NIST). This accomplishment marks a significant milestone in reinforcing trusted, standards-based encryption for organizations operating in regulated environments, including government agencies, healthcare institutions, and financial services.

OpenSSL 3.5 will be the next long term stable (LTS) release

We are pleased to announce that OpenSSL 3.5 will be the next long term stable (LTS) release. Per OpenSSL’s LTS policy, 3.5 will be supported until April 8, 2030.

The previous LTS (OpenSSL 3.0) will continue to be fully supported until September 7, 2025 and receive security fixes until September 7, 2026. Projects that currently depend on 3.0 are strongly encouraged to switch to OpenSSL 3.5 once it has been released.

In addition, the OpenSSL Corporation and Foundation have agreed to designate an LTS every two years. That means there will be an LTS release in April of 2027, another in 2029, and so on. As always, each LTS will be supported for 5 years with the final year’s support being security patches only. For more information, please see the OpenSSL Library Roadmap.

OpenSSL 3.5 Feature Branch Merge – Go/No-Go Decisions

We’re introducing a streamlined process for deciding which new features make it into each OpenSSL Library release. This involves two layers of readiness checks—technical and business—to help ensure features are both technically sound and well-aligned with the broader needs of the communities. For OpenSSL 3.5, the OpenSSL Technical Committee (OTC) has advised on technical readiness, and the Business Advisory Committee has advised on business readiness.

The go/no-go decisions ensure we merge well-vetted features into the main codebase for OpenSSL 3.5, complementing OpenSSL Library’s existing review process.

OpenSSL 3.5: Upcoming Release Announcement

The freeze date for OpenSSL 3.5 Alpha is rapidly approaching. If you have a feature on the planning page, please ensure that your associated PRs are posted, reviewed, and ready to be merged before the include/exclude decision date (Tuesday, February 11, 2025) and merged before the repository freeze date (Tuesday, February 25, 2025). Otherwise, the feature will be postponed until the next release.

Important dates

  • Feature branches include/exclude decision date: February 11, 2025
  • Feature branches merge: February 18, 2025
  • Repository freeze date: February 25, 2025
  • Alpha release date: March 11, 2025
  • Beta release date: March 25, 2025
  • Release date: April 8, 2025
release-3.5.svg

Current highlights of the feature list planned for 3.5 include:

  • QUIC server - QUIC (RFC 9000 - Quick UDP Internet Connections) is a protocol intended to deliver faster, secure communication for Internet applications. Standardized as RFC 9000, QUIC operates over UDP.
  • ML-KEM - Module Lattice Based Key Encapsulation Mechanism (FIPS 203), a post-quantum cryptography algorithm for key encapsulation for secure key exchange.
  • ML-DSA - Module Lattice Based Digital Signature Algorithm (FIPS 204), a post-quantum cryptography algorithm for signature generation and verification for proof of authenticity and non-repudiation.
  • SLH-DSA - Stateless Hash Based Digital Signature Algorithm (FIPS 205), a post-quantum cryptography algorithm for signature generation and verification for proof of authenticity and non-repudiation.

If you have any questions or comments regarding the OpenSSL 3.5 release contact us at feedback@openssl.org.

OpenSSL Position and Plans on Private Key Formats for the ML-KEM and ML-DSA Post-quantum (PQ) Algorithms

The anticipated future arrival of cryptographically relevant quantum computers (CRQCs), that could undermine the algorithms that underlie the currently most widely used public key algorithms (ECDHE, ECDSA, DH and RSA), has led to the development and recent standardisation of new “post-quantum” (PQ) algorithms, that are believed to not be vulnerable to CRQC attack.

Two of the first algorithms standardized are ML-KEM (for key agreement) and ML-DSA (for digital signatures). These algorithms are standardized by NIST in FIPS 203 and FIPS 204. These define the algorithm parameters and how to correctly perform the necessary mathematical operations, but do not define such details as data formats for public and private keys. Those details were left to other standards organisations, such as the IETF.