Jitter RNG

The CPU Jitter Random Number Generator provides a non-physical true random number generator that works equally in kernel and user land. The only prerequisite is the availability of a high-resolution timer that is available in modern CPUs.

GitHub Links

The source code of the following Jitter RNG components is publicly available:

• Jitter RNG Userspace Library

• Jitter RNG Daemon usable for Linux

Documentation

The reference to the applicable documentation is given with the various releases.

The latest documentation applies to the current version.

The Jitter RNG v2.2.0 documentation documents the Jitter RNG copy found in older Linux kernels.

Request For Help

I am looking for CPUs that are not listed in appendix F of the documentation. If you happen to have such a CPU with a Unix-ish operating system and you want to help me to gather more evidence on the appropriateness of the CPU Jitter random number generator, please perform the following:

1. Get the current library source code, unpack it

2. cd <librarydir>/tests/raw_entropy/recording_userspace

3. execute invoke_testing.sh

4. Send the result of the execution found in the directory results_measurements to me

Archive with Test Results

The archive with all collected test data is available at this location.

Historic Releases

For older releases, see the Jitter RNG historic page.

LRNG

The venerable Linux /dev/random served users of cryptographic mechanisms well for a long time. Its behavior is well understood to deliver entropic data. In the last years, however, the Linux /dev/random showed signs of age where it has challenges to cope with modern computing environments ranging from tiny embedded systems, over new hardware resources such as SSDs, up to massive parallel systems as well as virtualized environments. This paper proposes a new approach to entropy collection in the Linux kernel with the intention of addressing all identified shortcomings of the legacy /dev/random implementation. The new Linux Random Number Generator’s design is presented and all its cryptographic aspects are backed with qualitative assessment and complete quantitative testing. The test approaches are explained and the test code is made available to allow researchers to re-perform these tests.

The Linux Random Number Generator is an API and ABI compatible drop-in replacement to the legacy /dev/random implementation in the Linux kernel.

GitHub Links

The source code of the following LRNG components is publicly available:

• Linux Random Number Generator.

Documentation

The reference to the applicable documentation is given with the various releases.

Historic Releases

For older releases, see the LRNG historic page.

libkcapi

The Linux kernel exports a Netlink interface of type AF_ALG to allow user space to utilize the kernel crypto API.

libkcapi uses this Netlink interface and exports easy to use APIs so that a developer does not need to consider the low-level Netlink interface handling.

The library does not implement any cipher algorithms. All consumer requests are sent to the kernel for processing. Results from the kernel crypto API are returned to the consumer via the library API.

The kernel interface and therefore this library can be used by unprivileged processes.

The focus during the development of this library is put on speed. This library does not perform any memcpy for processing the cryptographic data! The library uses scatter / gather lists to eliminate the need for moving data around in memory.

GitHub Link

A public git repository is found at Github.

API Documentation

A full documentation is derived from the source code comments in kcapi-kernel-if.c.

See the README file enclosed in the source code for details on how to use the code.

See the TODO file enclosed in the source code for details on open items.

Historic Releases

For older releases, see the libkcapi historic page.

Leancrypto

The leancrypto library is moved to a new home.

ESDM

… or /dev/random in user space

The Entropy Source and DRNG Manager (ESDM) manages a set of deterministic random number generators (DRNG) and ensures their proper seeding and reseeding. To seed the DRNGs, a set of entropy sources are managed by the ESDM. The cryptographic strength of the entire ESDM is always 256 bits. All entropy processing is designed to maintain this strength.

Besides other services, it provides an API and ABI compliant drop-in replacement for the Linux /dev/random and /dev/urandom devices as well as the getrandom system call. This means it not only supports common users requesting random numbers, but also services using the IOCTLs documented in random(4) or using select(2) / poll(2) on the device files.

In addition to the Linux interface support, the ESDM provides a daemon managing the entropy sources and DRNG instances that can be accessed with a wrapper library. The ESDM requires only POSIX support along with protobuf-c and thus is intended to be executable on different operating systems.

It is extensible as follows:

• Additional entropy sources can easily be added, existing entropy sources can be deselected during compile time or its entropy rate altered during startup time.

• The cryptographic primitives can be altered by simply providing a new backend for hash algorithms or DRNG algorithms. See the drng_chacha20 configuration option replacing the SP800-90A DRBG with a ChaCha20-based DRNG, or the hash_sha3_512 configuration option replacing the SHA2-512 conditioning hash with SHA3-512.

• Different DRNG Seeding strategies can be defined, by modifying one location in the code that governs the initial and reseeding operation of the DRNGs.

The (re)seeding operation of the DRNG implements design ideas of the following specifications:

• SP800-90B: The entropy source of the Jitter RNG provides an SP800-90B compliant entropy source. In addition, the Intel RDSEED instruction is claimed to provide an SP800-90B entropy source. Also, when using the scheduler-based entropy source - which is only implemented for the Linux kernel using the code in addon/linux_esdm_es, a separate SP800-90B entropy source is provided. In addition, when using the interrupt-based entropy source - which is only implemented for the Linux kernel using the code in addon/linux_esdm_es, a separate SP800-90B entropy source is provided. If the kernel-based jitter entropy source shall be used, please compile your Linux kernel with CONFIG_CRYPTO_JITTERENTROPY.

• SP800-90C: The specification provides guidelines how to combine a DRNG and entropy sources.

Build

Use the Meson/Ninja build infrastructure with the following steps:

1. meson setup build

2. meson compile -C build

3. meson install -C build

Dependencies

The following dependencies are required:

• protobuf-c: When enabling any code beyond the ESDM library, the protobuf-c support is needed. Either the package of your favorite distribution must be installed or obtain the sources from the Protobuf-C Github website.

The following dependencies are required provided the respective functionality is enabled during compile time:

• Jitter RNG: If the Jitter RNG entropy source is enabled as a compile time option, install the Jitter RNG library from your distribution or from the Jitter RNG homepage.

• kcapi library: If the kernel-based jitter source is enabled as a compile time option, the kcapi library is required, either from your distribution or from the libkcapi website.

• SELinux library: If your system uses SELinux and you compile the CUSE device file support (compile time option), the SELinux library is needed for proper device file labeling. In this case, use the package from your distribution.

• FUSE 3 library: If the CUSE daemons shall be compiled and are enabled as a compile time option, the FUSE 3 library is required either from your distribution or from the libfuse Github website.

• Botan >= 3.0: If the Botan backend for cryptographic operations shall be used and is enabled as a compile time option, or if the Botan ESDM seed source shall be compiled when the compile time option is enabled get Botan either from your distribution or from the botan Github website.

• OpenSSL >= 3.0: If the OpenSSL backend for cryptographic operations shall be used and is enabled as a compile time option, or if the OpenSSL ESDM seed source shall be compiled when the compile time option is enabled, obtain OpenSSL either from your distribution or from the OpenSSL website.

• leancrypto: If the leancrypto backend for cryptographic operations shall be enabled during compile time, obtain leancrypto from the leancrypto website.

Beyond those dependencies, only POSIX support is required.

GitHub Link

A public git repository is provided with Github

Documentation

The reference to the applicable documentation is given with the various releases.

ACVP Parser

This parser implements the ACVP protocol used by NIST for the automated CAVP testing (Automated Cryptographic Validation Program - ACVP).

This parser processes JSON files that are already downloaded from the NIST ACVP server. It invokes the cryptographic implementation and generates the test response JSON data as defined by the ACVP protocol.

The entire ACVP server interaction including download of test vectors and upload of test responses must be handled with a separate tool, like the ACVP Proxy.

The following crypto implementations were successfully linked with and tested using the ACVP Parser:

• Jitter RNG conditioning function

• Linux /dev/random replacement implementation (LRNG) conditioning function

• ACVP Proxy hash and HMAC implementations

• Apple CommonCrypto

• Apple Corecrypto

• BoringSSL

• Botan

• BouncyCastle Java implementation accessed via the JNA interface

• GnuTLS

• Linux kernel crypto API using a kernel module written for the testing

• libkcapi

• libreswan

• libsodium

• NSS

• OpenSSH

• OpenSSL

• PKCS 11 Token

• Strongswan

In addition, the ACVP Parser is used to implement the following converters:

• Conversion of ACVP test vectors into CAVS format

• Conversion of CAVS test responses into ACVP test response format

No Runtime-Dependencies

The ACVP Parser is written in a clean C99 code and only requires the presence of a POSIX environment. It does not require any additional libraries or support functions and is therefore intended to be usable a large array of environments. For example, the ACVP Parser is successfully ported to iOS without requiring any code changes. Only a UI was required to be added to allow the application to be deployed.

GitHub Link

A public git repository is provided at Github.

ACVP Protocol Specification

The ACVP Parser implements the entire test vector JSON parsing of the ACVP Protocol Specification. It implements all aspects of the protocol.

Historic Releases

For older releases, see the ACVP Parser historic page.

ACVP Proxy

The ACVP Proxy allows the retrieving of test vectors from the ACVP servers. In addition, it allows the submission of test results to the ACVP servers and to retrieve the verdict of the test results.

The obtained test vectors stored in the files testvector-request.json are intended to be transferred to the test system hosting the cryptographic module to be tested. The JSON file must be inserted into the cryptographic module to produce the testvector-response.json file holding the responses according to the ACVP protocol specification. An example implementation that parses these JSON files, invokes the cryptographic implementation and generates the test response files, see the ACVP Parser.

Runtime-Dependencies

The ACVP Proxy is implemented in clean C99 and requires the presence of the POSIX API. In addition, the ACVP Proxy requires libcurl to be present. This library is commonly available to almost all general purpose operating systems. Other runtime-dependencies are not required. On Apple operating systems, the ACVP Proxy also supports the NSURL API.

The ACVP Proxy was successfully compiled and executed on the following operating systems:

• Linux

• macOS

• Windows

GitHub Link

A public git repository is provided at Github.

ACVP Protocol Specification

The ACVP Proxy implements the entire network side of the ACVP Protocol Specification. It implements almost all aspects of the protocol.

Historic Releases

For older releases, see the ACVP Proxy historic page.

Chacha20 DRNG

The ChaCha20 DRNG is a complete standalone implementation of a deterministic random number generator. It does not need any external cryptographic support.

It is implemented using ideas specified in SP800-90A, AIS 20/31 as well as specified by Peter Gutmann’s 1998 Usenix Security Symposium paper: “Software Generation of Practically Strong Random Numbers”. The following list enumerates the different properties offered with the ChaCha20 DRNG.

Different seed sources are implemented which are activated during compile time. This includes the support for the CPU Jitter Random Number Generator which makes the ChaCha20 DRNG fully standalone without the need of support from other cryptographic implementations. See the seed source documentation for details.

The ChaCha20 DRNG is derived from the “standalone” DRNG support implemented as part of the Linux Random Number Generator – a new approach to the Linux /dev/random.

GitHub Link

A public git repository is provided at Github.

API Documentation

A full documentation is derived from the source code comments in chacha20_drng.h.

See the README file enclosed in the source code for details on how to use the code.

Historic Releases

For older releases, see the ChaCha20 DRNG historic page.

Cryptoperf

The cryptoperf tool measures the execution speed of the kernel crypto API. The measurements are obtained by performing a crypto operation as often as possible within a given time frame.

The cryptoperf code base can be extended to cover additional ciphers by simply adding the kernel crypto API cra_name to the source code.

See the README file enclosed in the source code for details on how to use the code.

See the TODO file enclosed in the source code for details on shortcomings.

Source Code

The following source code contains the implementation of the Cryptoperf tool.

• Source Code

Papers

The papers are moved to a new home.

About This Site

Code Signing Certificate

All source code distributed on this web site is signed. In order to verify the signature and thus the integrity and authenticity of the obtained code, use the following command:

1

gpg --verify <SOMEFILE>.tar.xz.asc <SOMEFILE>.tar.xz

Replace <SOMEFILE> with the correct file name.

This command only performs the verification if the associated public key was previously imported into the key ring. In case the public key needs to be imported, use the following command which imports the key from 2024:

1

curl https://chronox.de/about/smuellerDD-2024.asc | gpg --import

The following public keys are available:

• Public key starting from 2024

• Public key starting from 2018