Between Now and Later: FIPS Compliance and Java Support for Ed25519
Background
The Federal Information Processing Standards define requirements for United States government systems, including specifications for computer security. FIPS 140-3 establishes requirements for cryptographic modules, enumerating allowed algorithms and parameters for data encryption and digital signatures. The Cryptographic Module Validation Program reviews hardware and software implementations for compliance with FIPS standards, issuing certificates for validated modules. This validation process is required for running in environments with stringent security controls, such as systems operating under the Federal Risk and Authorization Management Program. With official specifications and a common validation process, compliance with FIPS offers a clear baseline for secure computing. As an established standard, however, introducing changes to approved algorithms and parameters is a slow process.
Introduction
Daniel J. Bernstein published the Ed25519 specification for digital signatures using Edwards elliptic curves in 2011. RFC 8032 codified Ed25519 and Ed448 as variant implementations of the Edwards-curve Digital Signature Algorithm in 2017. With widespread adoption in popular libraries and services such as Bouncy Castle, OpenSSL, and OpenSSH, NIST added EdDSA and the Ed22519 implementation to a draft Digital Signature Standard FIPS 186-5 in 2019. Java 15 added direct support for EdDSA under JEP 339 in 2020. NIST published the final version of FIPS 186-5 in February 2023, opening the door for cryptographic module implementations to receive validation for implementations of Ed25519. For Java applications seeking compliance with FIPS standards, however, options remain limited as of February 2025.
Java and Ed25519
The Bouncy Castle Java FIPS API version 2.1.0 received approval under Certificate 4943 in January 2025 and the Bouncy Castle Roadmap for Java FIPS confirms support for EdDSA in 2.1.0. The Amazon Web Services libcrypto library version 3.0.0, which implements Ed25519 and provides the foundation for the Amazon Corretto Crypto Provider, is under review for FIPS certification. The current state of support for a certified FIPS implementation of Ed25519 in Java requires avoiding the algorithm for now, exposing algorithm selection as a configuration option, or considering feature detection for forward compatibility. Apache NiFi version 2.2.0 selected feature detection as an implementation strategy, supporting Ed25519 when it is available, and falling back to RSA for signing application JSON Web Tokens in the absence of Ed25519.
Apache NiFi Application Token Signing
Apache NiFi introduced asymmetric key cryptography for signing application session tokens in version
1.15.0
along with
other improvements around JSON Web Tokens. The
implementation used the JWT PS512 algorithm, short for RSA-PSS with SHA-512. RSA-PSS addresses some of the security
gaps in standard RSA signing with a public and private RSA key pair. RSA remains on the list of signing algorithms
approved under FIPS 140-3 and FIPS 186-5, making it a straightforward option for Java applications requiring compliance
with those standards.
With larger key sizes, however, RSA signatures impact the size of every authenticated HTTP request to Apache NiFi. With
Apache NiFi 2 moving to Java 21 as the minimum version, version
2.0.0-M4 changed the
framework implementation to use EdDSA with Ed25519 for signing and verifying application tokens. As described
in NIFI-13424, the Ed25519 implementation results in HTTP request
headers less than half the size of the RSA implementation. NiFi 2.0.0 and 2.1.0 retained Ed25519 as the standard
implementation for application token processing.
Security Policy Constraints
Following the release of NiFi 2.0.0 in November 2024, NIFI-14048 highlighted compatibility problems with the Ed25519 algorithm when attempting to run on Red Hat Enterprise Linux 9.5 configured with a cryptography policy enforcing compliance with FIPS. The FIPS security policy for RHEL 9.5 reflects the pace of implementation and certification of cryptographic modules providing Ed25519 according to FIPS 186-5. Although application security is a priority for the Apache NiFi project, the project does not provide official support for compliance with FIPS security policies. However, with the general goal of supporting deployment across different environments, the intermediate status of support for Ed25519 in Java Security Providers presented a choice of implementation solutions: reverting the implementation to RSA, introducing a new configuration property, or some other option.
Reverting to RSA would have maintained the historical implementation from NiFi 1.15.0, but it would also have left behind the performance and security improvements included with the switch to Ed25519. Adding a new configuration property with Ed25519 as the default would have avoided some of the issues, but it would have introduced a specialized setting with associated maintenance requirements. NiFi 2 removed significant amounts of legacy code, including several configuration properties, highlighting the commitment often required for configurable application features. With Ed25519 approved in FIPS 186-5 and several cryptographic modules in the process of validation, the lifespan for a new configuration property was also limited. For these reasons, algorithm feature detection emerged as the best implementation solution.
Algorithm Feature Detection
The java.security.Security
class provides methods for managing cryptographic algorithm providers and associated parameters. The class supports
enumerating configured providers and also adding new providers, which impacts the behavior of the entire Java Virtual
Machine. The class has several methods named getProviders(), including one that takes a filter string argument
and returns an array of
java.security.Provider
objects matching the filter. As described in the
method documentation,
the filter format consists of a cryptographic service and a cryptographic algorithm or service type. Finding providers
that support the Ed25519 algorithm for key pair generation can be achieved with a standard filter string.
Provider[] providers = Security.getProviders("KeyPairGenerator.Ed25519");
The array of providers returned is null when the Java Virtual Machine does not have a security provider that matches
the filter expression. This approach enabled runtime adaption in the NiFi framework security configuration, defaulting
to EdDSA with Ed25519 when available, and falling back to PS512 with RSA when required.
For standard distributions of OpenJDK, the
SunEC Provider
implements Ed25519 and other Elliptic Curve Cryptography algorithms. The default java.security configuration includes
the SunEC provider in the third position. As described in
Apache NiFi Pull Request 9603, the SunEC provider can be removed or replaced
in the java.security configuration to emulate the behavior of a cryptographic policy that blocks the use of Ed25519.
NiFi logs the signing algorithm selected at runtime at the information level.
Configured Key Pair Algorithm [Ed25519] for JSON Web Signatures
The log message appears in nifi-user.log when using the default Logback configuration.
Conclusion
Compliance with FIPS is perennial question for both engineers and executives. As a barrier of entry for deployment on most federal government system, FIPS compliance can make or break a particular solution. As a set of approved algorithms, FIPS also influences cryptographic choices for general system security. The status of Java support for Ed25519 in relation to FIPS 186-5 highlights the challenge of changing standards, requiring careful consideration of engineering solutions.