Reviewer: Stewart Bryant
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-tsvwg-tinymt32-01
Reviewer: Stewart Bryant
Review Date: 2019-05-08
IETF LC End Date: 2019-05-13
IESG Telechat date: Not scheduled for a telechat
Summary: A well written document. There are a few review comments below that
the authors should consider.
Major issues: None
Minor issues:
According to statistical tests (BigCrush in TestU01
<http://simul.iro.umontreal.ca/testu01/tu01.html> and AdaptiveCrush
<http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ADAPTIVE/>) the
quality of the outputs of TinyMT seems pretty good,
SB> It would be useful to the reader to specify "pretty good »
[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.
=========
The TinyMT32 PRNG initialization depends, among other things, on a
parameter set -- namely (mat1, mat2, tmat) --
SB> These probably need a few words of explanation on introduction.
[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).
========
static void tinymt32_next_state (tinymt32_t * s);
SB> I assume that this notation is good C, but
SB> type space star space name does not seem common.
SB> This may confuse some readers. One more often
SB> sees one of the spaces omitted.
[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).
=========
Nits/editorial comments:
This specialisation aims at having a simple-to-use and deterministic
PRNG, as explained below.
SB> I assume that "deterministic PRNG" is a term of the art, but the
SB> it sounds like an oxymoron to the uninitiated. Perhaps a word
SB> or two would clarify.
[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.
=======
