| Dear Stewart, Thanks a lot for your review. We have submitted a new I-D to reflect these changes. More precisely: Reviewer: Stewart Bryant [VR] Good point. This is a claim that comes from the TinyMT32 authors (also co-author of this I-D): A few things have been changed (mention to uniformity, addition of the above URL to know where the claim comes from, mention of the limitations of Park-Miller PRNG. But as explained, we can do better with Mersenne Twister PRNG (for instance), but it has a cost. None of them are considered cryptographically secure, which we now mention. NEW: The purpose of TinyMT is not to replace Mersenne Twister: TinyMT has a far shorter period (2^^127 - 1) than MT. The merit of TinyMT is in its small size of the internal state of 127 bits, far smaller than 19937 bits of MT. According to statistical tests (BigCrush in TestU01 [3] and AdaptiveCrush [4]) the quality of the outputs of TinyMT seems pretty good in terms of randomnes (in particular the uniformity of generated numbers), taking the small size of the internal state into consideration (see [5]). From this point of view, TinyMT32 represents a major improvement with respect to the Park-Miler Linear Congruential PRNG (e.g., as specified in [RFC5170]) that suffers several known limitations. However, neither TinyMT nor MT are meant to be used for cryptographic applications. ========= [VR] Agreed. We have extended this paragraph to be more clear. NEW: The TinyMT32 PRNG initialization depends, among other things, on a parameter set -- namely (mat1, mat2, tmat) -- that needs to be well chosen (pre-calculated values are available in the official web site). In order to facilitate the use of this PRNG and make the sequence of pseudo-random numbers depend only on the seed value, this specification requires the use of a specific parameter set (see Section 3.1). This is a first difference with respect to the implementation version 1.1 (2015/04/24) by Mutsuo Saito and Makoto Matsumoto that leaves this parameter set unspecified. A second difference is the removal of the tinymt32_init_by_array() alternative initialization function, to only keep the simple initialisation through a seed value (see Section 3.2). ======== [VR] Yes, let’s do that in the usual way. I’ve removed the extra space before the « * » (the opposite is possible too, with a subtil difference when several variables are defined together, which we avoid here). ========= [VR] Agreed. We have extended this paragraph as follows: NEW: Finally, the determinism of this PRNG, for a given seed, has been carefully checked (see Section 3.3). It means that the same sequence of pseudo-random 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 it the case with [RLC-ID] that normatively depends on this specification. ======= Cheers, Vincent |
