.\" Automatically generated by Pandoc 2.9.2.1
.\"
.TH "randombytes" "3" "" "" ""
.hy
.SS NAME
.PP
randombytes - fill a buffer with random data
.SS SYNOPSIS
.IP
.nf
\f[C]
#include <randombytes.h>

unsigned char x[xbytes];

randombytes(x,xbytes);
\f[R]
.fi
.PP
Link with \f[C]-lrandombytes\f[R].
.SS DESCRIPTION
.PP
\f[C]randombytes\f[R] sets \f[C]x[0]\f[R], \f[C]x[1]\f[R], \&...,
\f[C]x[xbytes-1]\f[R] to random bytes of data.
.PP
Randomness APIs vary in three major ways.
\f[C]randombytes\f[R] is designed in each way to simplify callers:
.IP \[bu] 2
Like \f[C]RAND_bytes\f[R], \f[C]randombytes\f[R] automatically generates
separate randomness for any number of bytes in any number of calls in
any number of threads in any number of programs.
For comparison, some randomness APIs (e.g., \f[C]random\f[R]) recycle
randomness from one program to another unless the program does extra
work to set a separate \[lq]seed\[rq], and can recycle randomness across
multiple threads unless the program does further work.
.IP \[bu] 2
Like \f[C]getrandom\f[R] and \f[C]getentropy\f[R] and
\f[C]RAND_bytes\f[R], \f[C]randombytes\f[R] aims for the stringent goal
of ensuring that no feasible computation will ever be able to tell the
difference between the output bytes and true randomness.
The caller can treat each returned byte as the result of 8 fresh coin
flips.
For comparison, some randomness APIs (e.g., \f[C]random\f[R]) do not aim
for this goal and do not view detectable patterns as a bug, as long as
\f[I]most\f[R] applications do not notice the patterns.
.IP \[bu] 2
Like \f[C]random\f[R], \f[C]randombytes\f[R] always succeeds.
Any necessary resources (e.g., opening a file descriptor for
\f[C]/dev/urandom\f[R], on systems that need this) are allocated at
program startup, rather than being deferred until the first
\f[C]randombytes\f[R] call; also, dynamic failure cases such as EINTR
are handled inside \f[C]randombytes\f[R].
For comparison, some randomness APIs (e.g., \f[C]getrandom\f[R] and
\f[C]getentropy\f[R] and \f[C]RAND_bytes\f[R]) can return error codes to
be handled by the caller.
.PP
There are some programs that try to close all file descriptors.
These programs must limit their library use to libraries that promise
not to keep file descriptors open.
In particular, these programs must not use \f[C]randombytes\f[R] (which
keeps a file descriptor open on some systems) or other libraries calling
\f[C]randombytes\f[R].
\[ga] ### LINK DETAILS
.PP
Currently \f[C]-lrandombytes\f[R] is a frontend symbolic link to either
\f[C]-lrandombytes-kernel\f[R] or \f[C]-lrandombytes-openssl\f[R] as a
backend library.
To simplify system-wide replacement of the backend library, typical
applications should dynamically link to \f[C]-lrandombytes\f[R] rather
than to \f[C]-lrandombytes-kernel\f[R] or
\f[C]-lrandombytes-openssl\f[R].
.PP
Applications that link statically to \f[C]-lrandombytes\f[R] also need
\f[C]-lcrypto\f[R] if \f[C]-lrandombytes\f[R] is
\f[C]-lrandombytes-openssl\f[R].
.PP
Currently \f[C]randombytes\f[R] is a macro, where the function actually
linked is \f[C]randombytes_internal_void_voidstar_longlong\f[R].
.SS HISTORY
.PP
The \f[C]randombytes\f[R] API was introduced in 2008 as part of the
SUPERCOP (https://bench.cr.yp.to) benchmarking framework for
cryptographic software.
.PP
Similar previous APIs include \f[C]RAND_bytes\f[R] and
\f[C]arc4random_buf\f[R], but \f[C]RAND_bytes\f[R] was allowed to return
failures and \f[C]arc4random_buf\f[R] was using the broken RC4 stream
cipher.
.SS SEE ALSO
.PP
\f[B]getrandom\f[R](2), \f[B]getentropy\f[R](2), \f[B]rand\f[R](3),
\f[B]random\f[R](3), \f[B]arc4random\f[R](3), \f[B]urandom\f[R](4)