Jitter Entropy in OpenSSL 3.x

OpenSSL 3.4.0 introduced the jitter‑based entropy source (JITTER) as an optional RNG seed, accessible when compiled with enable‑jitter. In OpenSSL 3.5.0 – the new long‑term stable (LTS) release – the jitter entropy provider remains available and gains further significance: notably, the FIPS provider can optionally utilize it via a new configuration flag, enable‑fips‑jitter. This makes OpenSSL 3.5.0 particularly compelling for users seeking stablity and flexibility across both standard and FIPS and Common Criteria use cases.

Compiling OpenSSL 3.5.0 with Jitter Entropy Support and FIPS Mode

To compile OpenSSL 3.5.0 with jitter support you must first obtain the jitterentropy-library source code and build it. OpenSSL will make use of the resultant static library (.a).

Configure the OpenSSL build with enable-jitter. This ensures the JITTER seed source is compiled in and appears in the output of openssl list -random-generators or openssl info -seeds. If you’re also targeting FIPS functionality, add both enable‑fips and enable‑fips‑jitter. The latter enables the FIPS provider to draw entropy from the jitter source.

If the jitterentropy-library is not already in a well-defined location, then you can optionally use --with-jitter-lib and --with-jitter-include to point to the location where the pre-compiled libjitterentropy.a and headers reside. On Linux, a typical build command-line might look like this:

./config enable-fips enable-jitter enable-fips-jitter --with-jitter-lib=/path/to/jitterentropy-library --with-jitter-include=/path/to/jitterentropy-library
make
make install

Note that the last step (make install) will automatically perform the documented openssl fipsinstall step. The resulting fipsmodule.cnf will be stored in the $PREFIX/ssl directory. You can manually verify if this configuration is complete (note that $PREFIX is a stand-in for your specific installation prefix which is /usr/local, by default):

openssl fipsinstall -module $PREFIX/lib64/ossl-modules/fips.so -in $PREFIX/ssl/fipsmodule.cnf -provider_name fips -verify

Verify Jitter Entropy Provider

Ensure that the Jitter entropy provider is enabled, using a minimal configuration file (which we will call “openssl-jitter-verify.cnf”) such as the following:

    openssl_conf = openssl_init

    [openssl_init]
    random = random

    [random]
    seed=JITTER

To confirm that the jitter seed source is active, you can:

• Run openssl list -random-generators or openssl info -seeds: you should see “JITTER” listed. (If you do not, then verify that the library installed in $PREFIX is part of your default library search path, such as LD_LIBRARY_PATH in Linux.)
• In code, fetch "JITTER" explicitly with EVP_RAND_fetch(NULL, "JITTER", ...) and check non‑NULL return values.
• When using FIPS with jitter (enable-fips-jitter), ensure the provider lists that option – though note this configuration requires testing by an accredited lab, such as Lightship Security, and validation by the Cryptographic Module Validation Program (CMVP), to be considered FIPS‑compliant.

$ OPENSSL_CONF=/tmp/openssl-jitter-verify.cnf openssl version -r
Seeding source: os-specific JITTER (3060400)
$ OPENSSL_CONF=/tmp/openssl-jitter-verify.cnf openssl list -random-generators
Provided RNGs and seed sources:
  CTR-DRBG @ default
  HASH-DRBG @ default
  HMAC-DRBG @ default
  JITTER @ default
  SEED-SRC @ default
  TEST-RAND @ default

You will likely see your seed sources described as “os-specific JITTER” (along with the JITTER version string — 3.6.4 is shown above). Historically, when multiple seed sources were listed, OpenSSL used them in a waterfall fashion by querying entropy seed sources as described in OpenSSL $SRC/providers/implementations/rand/seeding. However, when JITTER is listed, this provider takes precedence (unless explicitly overridden in code), and in fact, there is no fallback mechanism employed back to the os-specific provider if the JITTER implementation fails to acquire enough entropy.

To test failure and fallback conditions, we constructed an instrumented and lightly modified build of OpenSSL 3.5.0 where we inform the user where the source of entropy is coming from (“Called …”), and also force the Jitter entropy provider to return 0 bits. If Jitter entropy fails to acquire enough entropy, then a seeding call will fail outright:

$ OPENSSL_CONF=/tmp/openssl-jitter-verify.cnf openssl rand -hex 32
Called ossl_prov_acquire_entropy_from_jitter
802BDB902F7F0000:error:1C8000BA:Provider routines:jitter_get_seed:entropy source strength too weak:providers/implementations/rands/seed_src_jitter.c:297:
802BDB902F7F0000:error:1C8000BD:Provider routines:ossl_prov_drbg_instantiate:error retrieving entropy:providers/implementations/rands/drbg.c:444:
802BDB902F7F0000:error:1200006C:random number generator:rand_new_drbg:error instantiating drbg:crypto/rand/rand_lib.c:717:

Failure modes are important to understand, especially when making claims of usage in Common Criteria.

FIPS Mode

FIPS mode requires the fips.so provider to be enabled and activated. This can be done using a variety of means. We will control it using a configuration file (we call ours openssl-fips-jitter.cnf; replace $PREFIX with your explicit install path) so that we can also enable the JITTER seeding source:

    openssl_conf = openssl_init
    .include $PREFIX/ssl/fipsmodule.cnf

    [openssl_init]
    providers = provider_sect
    alg_section = evp_properties
    random = random

    [evp_properties]
    default_properties = "fips=yes"

    [random]
    seed=JITTER

    [provider_sect]
    fips = fips_sect  # Must match section header in the .included file above

When using the FIPS provider with our instrumented build that describes the source of entropy, we can see that Jitter is invoked with the FIPS provider enabled:

$ OPENSSL_CONF=/tmp/openssl-fips-jitter.cnf openssl list -random-generators
Provided RNGs and seed sources:
  CTR-DRBG @ fips
  HASH-DRBG @ fips
  HMAC-DRBG @ fips
  JITTER @ fips
$ OPENSSL_CONF=/tmp/openssl-fips-jitter.cnf openssl rand -hex 32
Called ossl_prov_acquire_entropy_from_jitter
8fff817ac22be1594dc05c956a884f13af62a3a06ed178ada52e1f50b30710da

Conclusion

OpenSSL’s inclusion of jitterentropy as an alternative third-party entropy provider is a key step to making your FIPS and Common Criteria journey easier and less error-prone.

 

Contact Lightship Security today to discuss how we can support your OpenSSL deployment for FIPS and Common Criteria — from configuration to compliance.