1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
### NAME
randombytes - fill a buffer with random data
### SYNOPSIS
#include <randombytes.h>
unsigned char x[xbytes];
randombytes(x,xbytes);
Link with `-lrandombytes`.
### DESCRIPTION
`randombytes` sets `x[0]`, `x[1]`, ..., `x[xbytes-1]` to random bytes of
data.
Randomness APIs vary in three major ways. `randombytes` is designed in
each way to simplify callers:
* Like `RAND_bytes`, `randombytes` 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., `random`) recycle randomness from one program
to another unless the program does extra work to set a separate
"seed", and can recycle randomness across multiple threads unless the
program does further work.
* Like `getrandom` and `getentropy` and `RAND_bytes`, `randombytes` 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.,
`random`) do not aim for this goal and do not view detectable patterns
as a bug, as long as _most_ applications do not notice the patterns.
* Like `random`, `randombytes` always succeeds. Any necessary resources
(e.g., opening a file descriptor for `/dev/urandom`, on systems that
need this) are allocated at program startup, rather than being
deferred until the first `randombytes` call; also, dynamic failure
cases such as EINTR are handled inside `randombytes`. For comparison,
some randomness APIs (e.g., `getrandom` and `getentropy` and
`RAND_bytes`) can return error codes to be handled by the caller.
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
`randombytes` (which keeps a file descriptor open on some systems) or
other libraries calling `randombytes`.
### LINK DETAILS
Currently `-lrandombytes` is a frontend symbolic link to either
`-lrandombytes-kernel` or `-lrandombytes-openssl` as a backend library.
To simplify system-wide replacement of the backend library, typical
applications should dynamically link to `-lrandombytes` rather than to
`-lrandombytes-kernel` or `-lrandombytes-openssl`.
Applications that link statically to `-lrandombytes` also need
`-lcrypto` if `-lrandombytes` is `-lrandombytes-openssl`.
Currently `randombytes` is a macro, where the function actually linked
is `randombytes_internal_void_voidstar_longlong`.
### HISTORY
The `randombytes` API was introduced in 2008 as part of the
[SUPERCOP](https://bench.cr.yp.to)
benchmarking framework for cryptographic software.
Similar previous APIs include `RAND_bytes` and `arc4random_buf`, but
`RAND_bytes` was allowed to return failures and `arc4random_buf` was
using the broken RC4 stream cipher.
### SEE ALSO
**getrandom**(2), **getentropy**(2), **rand**(3), **random**(3),
**arc4random**(3), **urandom**(4)
|
