| Internet-Draft | 4086bis | October 2026 |
| Miller & Salz | Expires 11 April 2027 | [Page] |
Things have changed a great deal in the two decades since RFC 4086, "Randomness Requirements for Security," was published. Notably, facilities to generate high-quality random numbers are widely available on most common computing platforms.¶
While RFC 4086 provides much information to those implementing such a facility, this document takes a different approach, encouraging implementors to use facilities already available to them.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/richsalz/ietf-4086bis.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Things have changed a great deal in the two decades since RFC 4086, "Randomness Requirements for Security," was published. Notably, facilities to generate high-quality random numbers are widely available on most common computing platforms.¶
While RFC 4086 provides much information to those implementing such a facility, this document takes a different approach, encouraging implementors to use facilities already available to them.¶
This document first defines some commonly-used terms in the generation of random numbers. This is followed by a short section that uses those terms to define a best practice for generating random numbers. This is followed by a section that lists some common concerns and mistakes, and may be thought of as a "Security Considerations" guide for implementors. Finally, the document concludes with the standard IETF boilerplate sections.¶
The following sub-sections define commonly-used terms. These are often mis-used, so the goal is to provide a common understanding. All of the definitions below should be taken in the context of cryptography.¶
When used in information science,
entropy is the amount of information, expressed in units of bits, that is
unknown to some other party (such as an attacker) in some scenario. For
example, to someone having no information about the actual outcome, "a value
chosen by a single flip of an ideal coin" would present an entropy of 1.0
bits, while "a sequence of 256 such flips" would present 256.0 bits. A
variable or protocol field of N bits can never represent more than N bits of
entropy. The effective entropy encoded in actual data is often significantly
less.¶
Sufficient entropy is a necessary (but not sufficient) property for a secure random number generation system. Without sufficient entropy the system may be predictable.¶
Good sources of entropy include values generated from hardware, such as
disk or network timings.
Common server systems often repeat the same actions every time the boot,
which means that system-provided entropy might not be immediately
available.
Many hardware systems provide RNG facilities that may be used as
entropy sources, such as rdrand/rdseed on X86 class CPUs, and
RNDR registers on
ARM CPUs.¶
Combination of multiple entropy sources is desirable where possible, to avoid failure if one of them turns out to be predictable.¶
A seed is the specific value used to initialize an algorithm that generates a sequence of unpredictable "random" numbers. The seed value should have high entropy. It is important that the seed not be disclosed, as an adversary could duplicate the bytes generated by the algorithm and determine any keys generated.¶
A nonce is a number that is used once. It need not be secret, and is often public or part of the protocol. For example, QUIC defines a nonce that is used to detect if a packet has already been received.¶
The non-repeatability can be highly important. For example, if AES-GCM repeats a nonce, an adversary can determine the key. AES-SIV is resistant to this. It is common for a nonce to be a simple incrementing counter.¶
In many protocols, nonce values are sent in cleartext. For example, the initial SSH key exchange (RFC 4253 section 7.1) includes a 16 byte "cookie" that each peer sends to make each key exchange (statistically) unique. A nonce that directly uses the RNG output, as opposed to hashing it, therefore represent one path by which an attacker may directly observe the raw output of a random number system.¶
A device or algorithm that produces a sequence of bits that have the following two characteristics:¶
It is statistically independent: knowing one bit provides no information about the value of any other bit; and¶
It is unbiased: no value is more likely to occur than any other value. See Section 4.4 for concerns about bias.¶
An RBG that uses a seed and produces random bits. The security of the stream requires that the the seed is not known by an adversary. The output stream has a defined limit, and the DRBG will need to be provided new seed material when the limit is reached. See [NISTDRBG] for more complete specification and algorithm descriptions.¶
A casual term that, when feasible, should be avoided.¶
A more accurate term than RNG. It can imply that the seed need not be kept private, such as when using the output stream for simulations.¶
If an adversary knows the state of the RBG at a time T, they will be unable
to recover the state at time T-1. Further, all output up to time T-1
cannot be distinguished from random output. This is usually accomplished by
ensuring that the RBG generation algorithm is a one-way function.¶
Put another way, backtracking resistance means that a compromise of the RBG internal state has no effect on the security of prior outputs. This is commonly called "forward secrecy" in protocols such as TLS.¶
If an adversary knows the state of the RBG at a time T, they will be unable
to predict the output at a time, T+1. This can only be provided by
ensuring that a RBG is reseeded between consecutive requests, as long as
knowledge of the current RBG internal state does not allow an adversary any
useful knowledge about future RBG internal states or outputs.¶
Use an appropriate function from the local operating system if available.
At the time of writing,
on Windows use the BCryptGenRandom() function described in [BCRYPT].¶
For OpenBSD 2.1, FreeBSD 3.0, NetBSD 1.6, DragonFly 1.0, or Linux C
library since July 2022 use the arc4random() described in [ARC4RAND].
The getrandom() function is also available on many systems and
is described in [GETRAND].¶
On older Unix-like systems, the /dev/random or /dev/urandom
pseudo-devices may be available; check the documentation.
Historically, he primary difference is that the first would block if the kernel
believed there is not enough entropy in the seed material; this may no
longer be true.¶
If the operating system does not provide something suitable, use an
OpenSSL function
from the RAND_bytes set described in [RANDBYTES], particularly if provided
as part of the operating system distribution as it is most likely to
enable the best source of entropy for seeding.
If the library must be configured and compiled directly,
see the notes in [OSSLCONFIG] about
random number generation.¶
If feasible, use a main DRBG to seed two separate DRBG's: one to generate private keys, and one for all other uses.¶
For smaller systems that are not generating cryptographic material, the Mersenne Twister PRNG may be acceptable. A full description and sample code can be found at [TWIST].¶
This section details some likely concerns and issues to consider.¶
A DRBG needs to be reseeded with additional entropy. The same sources used to provide the intial entropy can often be used in reseeding. The reseeding requirements depend on the DRBG implementation details; [NISTDRBG] provides an overview and some specifics. This is generally not necessary if the random bits are provided directly by the operating system.¶
When a system boots, or re-boots, the hardware used (or measured) to provide the seed material is often in the same state every time. This leads to repeated bitstreams across reboots. It is tempting to store seed material in local storage and use it at system start-up. If that file is accessible to an adversary, the stream of bits can be predictable.¶
It's common for a server to fork a separate client process for each incoming connection, or pre-create a pool to handle client requests. Reset the RNG when forking.¶
Modulo bias is a statistical distortion that happens when mapping a
a larger range of random numbers into a smaller range using a
modulo operation such as C's % operator.
For example, mapping the eight values [0 .. 7] to
the five values [0 .. 4] will be distorted because four is the
only value produced from only one input. This is a concern when the
upper bound isn't a power of two.¶
Use the arc4random_uniform() function if it is available.
Freely-available source can be found at [A4USRC].¶
This is an important document!¶
Stepehen: Look at what RFC9846, appendix C1 says. And others?¶
Draft 1: Fix typo's (ispell). This document no longer obsoletes RFC 4086, but provides different guidance for users of random numbers, not implementors thereof. Remove suggestions to copy text from RFC 4086; this no longer obsoletes that RFC but explains why this provides new guidance. Add RNG and clarify PRNG definitions. Various clarifying edits (Dan Wing). Rewrite entropy definition (Marsh Ray). Don't mention mouse as an entropy source; placeholder for Hardware RNG considerations (Adam Shostack). Give historic difference between /dev/*random (Stephen Farrell)¶
Draft 0: Published, asked for DISPATCH and CC'd SAAG.¶