Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-tinymt32-01
Vincent Roca <vincent.roca@inria.fr> Thu, 16 May 2019 16:03 UTC
Return-Path: <vincent.roca@inria.fr>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5652A1200EF; Thu, 16 May 2019 09:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BAziXtD2d0-9; Thu, 16 May 2019 09:03:41 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C72120074; Thu, 16 May 2019 09:03:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,477,1549926000"; d="scan'208,217";a="306293232"
Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2019 18:03:31 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Message-Id: <08DF989D-17BE-47AE-9E8F-A087BC7F607E@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_36C06F64-50DA-4FD3-8FAA-6E0339CC1E5C"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Thu, 16 May 2019 18:03:30 +0200
In-Reply-To: <155731992421.22706.18402243276597862967@ietfa.amsl.com>
Cc: Vincent Roca <vincent.roca@inria.fr>, gen-art@ietf.org, ietf@ietf.org, draft-ietf-tsvwg-tinymt32.all@ietf.org, tsvwg@ietf.org
To: Stewart Bryant <stewart.bryant@gmail.com>
References: <155731992421.22706.18402243276597862967@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/VsV9MPyXgNjAGEuNEYqS_EW2-M8>
Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-tinymt32-01
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2019 16:03:46 -0000
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>. > > 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): 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
- [tsvwg] Genart last call review of draft-ietf-tsv… Stewart Bryant via Datatracker
- Re: [tsvwg] Genart last call review of draft-ietf… Vincent Roca
- Re: [tsvwg] [Gen-art] Genart last call review of … Alissa Cooper