Re: [tsvwg] [Gen-art] Genart last call review of draft-ietf-tsvwg-tinymt32-01

[Alissa Cooper <[e-mail]>]

Stewart, thanks for your review. Vincent, thanks for your responses. I entered a No Objection ballot.

Alissa

> On May 16, 2019, at 12:03 PM, Vincent Roca <[e-mail]> wrote:
> 
> Dear Stewart,
> 
> Thanks a lot for your review. We have submitted a new I-D to reflect these changes.
> More precisely:
> 
>> 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 <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 <http://simul.iro.umontreal.ca/testu01/tu01.html>> and AdaptiveCrush
>> <http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ADAPTIVE/ <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):
> 	http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/TINYMT/index.html <http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/TINYMT/index.html>
> 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.
> 
> 
>> =======
> 
> Cheers,
> 
>    Vincent
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>