librandombytes provides a simple API for applications generating fresh
whenever desired to generate fresh random bytes
x[xbytes-1], and link with
Random bytes are often used directly in applications. Random bytes are also the foundation of more complicated random objects, such as random integers in a limited interval, random floating-point numbers from a (nearly) normal distribution, and random keys used in public-key cryptosystems. librandombytes is dedicated to obtaining fresh random bytes in the first place, and leaves it to higher-level libraries to convert those bytes into other types of random objects.
librandombytes aims for the following stringent randomness goal: no
feasible computation will ever be able to tell the difference between
the output bytes and true randomness (independent uniformly distributed
random bytes). This makes the
randombytes() output suitable for use
in applications ranging from simulations to cryptography.
Most alternative sources of randomness (such as
in C, and
mt19937_64 in C++) consider detectable deviations from true
randomness to be acceptable as long as most applications do not notice
the deviations. These sources are not permitted inside librandombytes;
randombytes() caller is entitled to expect that the output comes
from sources that are designed for the right goal.
Internally, librandombytes is an abstraction layer for a choice of two
libraries, where each library provides the same
but the libraries choose two different sources of randomness:
librandombytes-kernelreads random bytes provided by the OS kernel via mechanisms such as
getrandom(). These mechanisms are typically advertised as providing RNG security features that are harder to provide in user space, such as hypervisor integration.
RAND_bytesto generate random bytes. This mechanism is typically advertised as providing speed that is difficult to achieve without a per-process RNG.
The idea is that the OS can install
librandombytes-kernel by default,
but the sysadmin can install
librandombytes-openssl to transparently
switch all of the
randombytes() applications to
example, via Debian's
/etc/alternatives mechanism) if profiling
shows that this switch is important for overall system performance.
Making this choice centrally means that applications are free to simply
without worrying about evaluating performance,
without worrying about how to balance performance concerns with competing concerns, and
without worrying that these performance evaluations will be rendered obsolete by speed improvements: for example, by ongoing work to accelerate
getrandom(), or by the increasing deployment of fast-key-erasure RNGs.
Another virtue of having a
randombytes() abstraction layer is that
test frameworks can substitute a deterministic seeded
providing known pseudorandom bytes for reproducible tests. Of course,
randombytes() provided by these test frameworks must be kept
separate from the fresh
randombytes() used for deployment.
Version: This is version 2023.09.04 of the "Intro" web page.