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

Alissa Cooper <alissa@cooperw.in> Wed, 29 May 2019 19:49 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD4C120148; Wed, 29 May 2019 12:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ly4m7jVS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PHXYYnbm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAiMXWJHEtAw; Wed, 29 May 2019 12:49:09 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72B9120125; Wed, 29 May 2019 12:49:09 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B34892213D; Wed, 29 May 2019 15:49:08 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 29 May 2019 15:49:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=3lRw+D3dAUDHFY0KY9qcKRk 29lGl2MkQR9LUthmsrLs=; b=ly4m7jVSlZ/7uC4dYV/UqmsApuc30uSaV3809Kv FLAtcQvYBvW9Zinmmo5pQKRoIwxKr8YTilabF/aBGE1g7RddzRR7ltJKx/cv8UWn 6ndfmIYGn8dvk8u7rKO2DQTu2opj/UUuOW+2HRZxqRuIDlALEvQKj5Gx7Fuigwzq lUN09vzelXb9oHkMe///0+iRU2f8Eec1pgBR16oTGpybVDYYULVLtBB7VnnakEtk 5oKUgwanPiCeYQn/XSotz8Ko3cC1tEOo8I8r5j/1u0akqUkDvTO0c9AxRcK8myrD 9TYeCsSZfn+t3nFqTYIRArJ1eI7dwOVWEI7h5TdpNICJ90Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3lRw+D 3dAUDHFY0KY9qcKRk29lGl2MkQR9LUthmsrLs=; b=PHXYYnbmkXL9WXcV15I8tu YboG7a/JjU+zIArvm4qHZSn7Sa48GusEIg9+QNNCjykJZy84ifZ9RJWMzRp4xhYR Rl2d/Do1jhODnQ19SKNE0X3+AdTdzGqr8b2uYN9cDdBUaQ8Un3BDFUvDds37ZGFG oQlNdcIT/wophS4tGimYK93B4wR7ztVaxUuMECvj6y8nvatEW7yBSETD7jSHIbjD K5/flhsaPxNc00AxFTaZ8Fge0le5mhgViN2JAC3UpR3x5+i3lkB7PX8k6azQixFC k9EiA73sbvS1K5xdmW8Ey/9N5EKSzrmtvKoqYspizqmShtrbYBjLvU67PRN0Wtsg ==
X-ME-Sender: <xms:NOLuXCjRA3_n6yPd1cYjlFjFO9zmYSNGH2pgD6z8yO7qo-iYrEXACw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvjedgudeggecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepuhhmohhnthhrvggrlhdrtggrpdhivghtfhdrohhrghdphhhirhhoshhhihhmrgdq uhdrrggtrdhjphenucfkphepudejfedrfeekrdduudejrdekfeenucfrrghrrghmpehmrg hilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvghrufhi iigvpedt
X-ME-Proxy: <xmx:NOLuXNYSn4qa57iRL55rMau596HZHtl085vUp6B1coD8Ax4f_ji2zA> <xmx:NOLuXAPptY7CSJPGFlsH532c3rVnmb5HbXb53wo1-4zmvgu8GITdEA> <xmx:NOLuXGYM-Lbn15_pUUwZlHHDsgjLGVLLyLzszWZFsFQmgPx_ItVl7g> <xmx:NOLuXN3ZT1AWrei-Xe6GCLCvsYYMoGqPp4kvkN34ZEU3ZzX9dkYAfQ>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.83]) by mail.messagingengine.com (Postfix) with ESMTPA id 83BC88005C; Wed, 29 May 2019 15:49:07 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Message-Id: <8C025BE5-2892-45AC-AC7D-F46AB2EF47F5@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6209D625-3835-4543-B36A-9F1490D7432B"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 29 May 2019 15:49:05 -0400
In-Reply-To: <08DF989D-17BE-47AE-9E8F-A087BC7F607E@inria.fr>
Cc: tsvwg@ietf.org, IETF Gen-ART <gen-art@ietf.org>, draft-ietf-tsvwg-tinymt32.all@ietf.org, ietf <ietf@ietf.org>
To: Vincent Roca <vincent.roca@inria.fr>, Stewart Bryant <stewart.bryant@gmail.com>
References: <155731992421.22706.18402243276597862967@ietfa.amsl.com> <08DF989D-17BE-47AE-9E8F-A087BC7F607E@inria.fr>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/fzlqHa0NUTcRMYte6jD20NjF8Ho>
Subject: Re: [Gen-art] [tsvwg] Genart last call review of draft-ietf-tsvwg-tinymt32-01
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 19:49:13 -0000

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 <vincent.roca@inria.fr>; 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
> Gen-art@ietf.org <mailto:Gen-art@ietf.org>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>