RFC 8682: TinyMT32 Pseudorandom Number Generator (PRNG)
- M. Saito,
- M. Matsumoto,
- V. Roca, Ed.,
- E. Baccelli
Abstract
This document describes the TinyMT32 Pseudorandom Number Generator (PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller Linear Congruential PRNG. However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2020 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://
1. Introduction
This document specifies the TinyMT32 PRNG as a specialization of the reference implementation version 1.1 (2015/04/24) by Mutsuo Saito and Makoto Matsumoto from Hiroshima University, which can be found at [TinyMT-web] (the TinyMT website) and [TinyMT-dev] (the GitHub site). This specialization aims at having a simple-to-use and deterministic PRNG, as explained below. However, the TinyMT32 PRNG is not meant to be used for cryptographic applications.¶
TinyMT is a new, small-sized variant of the Mersenne Twister (MT) PRNG introduced in 2011 [MT98]. This document focuses on the TinyMT32 variant (rather than TinyMT64) of the TinyMT PRNG, which outputs 32-bit unsigned integers.¶
The purpose of TinyMT is not to replace the Mersenne Twister: TinyMT has a far shorter period (2127 - 1) than MT.
The merit of TinyMT is in the small size of the 127-bit internal state, far smaller than the 19937 bits of MT.
The outputs of TinyMT satisfy several statistical tests for non
The TinyMT32 PRNG initialization depends, among other things, on a parameter set, namely (mat1, mat2, tmat). In order to facilitate the use of this PRNG and to make the sequence of pseudorandom numbers depend only on the seed value, this specification requires the use of a specific parameter set (see Section 2.1). This is a major difference with respect to the implementation version 1.1 (2015/04/24), which leaves this parameter set unspecified.¶
Finally, the determinism of this PRNG for a given seed has been carefully checked (see Section 2.3). This means that the same sequence of pseudorandom numbers should be generated, no matter the target execution platform and compiler, for a given initial seed value. This determinism can be a key requirement, as is the case with [RFC8681], which normatively depends on this specification.¶
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
2. TinyMT32 PRNG Specification
2.1. TinyMT32 Source Code
The TinyMT32 PRNG must be initialized with a parameter set that needs to be well chosen. In this specification, for the sake of simplicity, the following parameter set MUST be used:¶
This parameter set is the first entry of the precalculated parameter sets in tinymt32dc
The TinyMT32 PRNG reference implementation is reproduced in Figure 1. This is a C language implementation written for C99 [C99]. This reference implementation differs from the original source code as follows:¶
2.2. TinyMT32 Usage
This PRNG MUST first be initialized with the following function:¶
It takes as input a 32-bit unsigned integer used as a seed (note that value 0 is permitted by TinyMT32). This function also takes as input a pointer to an instance of a tinymt32_t structure that needs to be allocated by the caller but is left uninitialized. This structure will then be updated by the various TinyMT32 functions in order to keep the internal state of the PRNG. The use of this structure admits several instances of this PRNG to be used in parallel, each of them having its own instance of the structure.¶
Then, each time a new 32-bit pseudorandom unsigned integer between 0 and 232 - 1 inclusive is needed, the following function is used:¶
Of course, the tinymt32_t structure must be left unchanged by the caller between successive calls to this function.¶
2.3. Specific Implementation Validation and Deterministic Behavior
For a given seed, PRNG determinism can be a requirement (e.g., with [RFC8681]).
Consequently, any implementation of the TinyMT32 PRNG in line with this specification MUST have the same output as that provided by the reference implementation of Figure 1.
In order to increase the compliancy confidence, this document proposes the following criteria.
Using a seed value of 1, the first 50 values returned by tinymt32
In particular, the deterministic behavior of the Figure 1 source code has been checked across several platforms:
high-end laptops running 64-bit Mac OS X and Linux/Ubuntu;
a board featuring a 32-bit ARM Cortex-A15 and running 32-bit Linux/Ubuntu;
several embedded cards featuring either an ARM Cortex-M0+, a Cortex-M3, or a Cortex-M4 32-bit microcontroller
This specification only outputs 32-bit unsigned pseudorandom numbers and does not try to map this output to a smaller integer range (e.g., between 10 and 49 inclusive). If a specific use case needs such a mapping, it will have to provide its own function. In that case, if PRNG determinism is also required, the use of a floating point (single or double precision) to perform this mapping should probably be avoided, as these calculations may lead to different rounding errors across different target platforms. Great care should also be taken to not introduce biases in the randomness of the mapped output (which may be the case with some mapping algorithms) incompatible with the use-case requirements. The details of how to perform such a mapping are out of scope of this document.¶
3. Security Considerations
The authors do not believe the present specification generates specific security risks per se. However, the TinyMT and MT PRNG must not be used for cryptographic applications.¶
4. IANA Considerations
This document has no IANA actions.¶
5. References
5.1. Normative References
- [C99]
- International Organization for Standardization, "Programming languages - C: C99, correction 3:2007", ISO/IEC 9899:1999/Cor 3:2007, .
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174
5.2. Informative References
- [AdaptiveCrush]
-
Haramoto, H., "Automation of Statistical Tests on Randomness to Obtain Clearer Conclusion", Monte Carlo and Quasi-Monte Carlo Methods 2008, DOI 10
.1007 , , <http:///978 -3 -642 -04107 -5 _26 www >..math .sci .hiroshima -u .ac .jp /~m -mat /MT /ADAPTIVE - [Baccelli18]
-
Baccelli, E., Gundogan, C., Hahm, O., Kietzmann, P., Lenders, M. S., Petersen, H., Schleiser, K., Schmidt, T. C., and M. Wahlisch, "RIOT: An Open Source Operating System for Low-End Embedded Devices in the IoT", IEEE Internet of Things Journal, Volume 5, Issue 6, DOI 10
.1109 , , <https:///JIOT .2018 .2815038 doi >..org /10 .1109 /JIOT .2018 .2815038 - [KR12]
-
Rikitake, K., "TinyMT pseudo random number generator for Erlang", Proceedings of the 11th ACM SIGPLAN Erlang Workshop, pp. 67-72, DOI 10
.1145 , , <https:///2364489 .2364504 doi >..org /10 .1145 /2364489 .2364504 - [MT98]
-
Matsumoto, M. and T. Nishimura, "Mersenne twister: A 623
-dimensionally equidistributed uniform pseudo-random number generator" , ACM Transactions on Modeling and Computer Simulation (TOMACS), Volume 8, Issue 1, pp. 3-30, DOI 10.1145 , , <https:///272991 .272995 doi >..org /10 .1145 /272991 .272995 - [PTVF92]
- Press, W., Teukolsky, S., Vetterling, W., and B. Flannery, "Numerical recipes in C (2nd ed.): the art of scientific computing", Cambridge University Press, ISBN 0-521-43108-5, .
- [RFC5170]
-
Roca, V., Neumann, C., and D. Furodet, "Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes", RFC 5170, DOI 10
.17487 , , <https:///RFC5170 www >..rfc -editor .org /info /rfc5170 - [RFC8681]
-
Roca, V. and B. Teibi, "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME", RFC 8681, DOI 10
.17487 , , <https:///RFC8681 www >..rfc -editor .org /info /rfc8681 - [TestU01]
-
L'Ecuyer, P. and R. Simard, "TestU01: A C library for empirical testing of random number generators", ACM Transactions on Mathematical Software (TOMS), Volume 33, Issue 4, Article 22, DOI 10
.1145 , , <http:///1268776 .1268777 simul >..iro .umontreal .ca /testu01 /tu01 .html - [TinyMT-dev]
-
"Tiny Mersenne Twister (TinyMT)", commit 9d7ca3c, , <https://
github >..com /Mersenne Twister -Lab /Tiny MT - [TinyMT-params]
-
"TinyMT pre-calculated parameter list", commit 30079eb, , <https://
github >..com /jj1bdx /tinymtdc -longbatch - [TinyMT-web]
-
Saito, M. and M. Matsumoto, "Tiny Mersenne Twister (TinyMT)", <http://
www >..math .sci .hiroshima -u .ac .jp /~m -mat /MT /TINYMT /
Acknowledgments
The authors would like to thank Belkacem Teibi, with whom we explored TinyMT32 specificities when looking to an alternative to the Park-Miller Linear Congruential PRNG. The authors would also like to thank Carl Wallace; Stewart Bryant; Greg Skinner; Mike Heard; the three TSVWG chairs, Wesley Eddy (our shepherd), David Black, and Gorry Fairhurst; as well as Spencer Dawkins and Mirja Kuehlewind. Last but not least, the authors are really grateful to the IESG members, in particular Benjamin Kaduk, Eric Rescorla, Adam Roach, Roman Danyliw, Barry Leiba, Martin Vigoureux, and Eric Vyncke for their highly valuable feedback that greatly contributed to improving this specification.¶