Re: [secdir] secdir review of draft-ietf-tsvwg-tinymt32

Vincent Roca <> Mon, 27 May 2019 09:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D629912004B; Mon, 27 May 2019 02:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cVtWDaCSrd86; Mon, 27 May 2019 02:02:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1A9D12003E; Mon, 27 May 2019 02:02:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,518,1549926000"; d="scan'208,217";a="307294113"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2019 11:02:08 +0200
From: Vincent Roca <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E8E2E11C-FE99-43B1-8413-6E7BE460830E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 27 May 2019 11:02:07 +0200
In-Reply-To: <>
Cc: Vincent Roca <>,,,
To: Carl Wallace <>
References: <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-tinymt32
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 May 2019 09:02:22 -0000

Hello Carl, all,

Thanks a lot for your secdir review.

> Le 17 mai 2019 à 20:38, Carl Wallace <> a écrit :
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> This document describes the TinyMT32 Pseudo Random Number Generator (PRNG)
> that produces 32-bit pseudo-random unsigned integers and aims at having a
> simple-to-use and deterministic solution. The document is well written and
> the sample code produces the sample output. I am not a mathematician so no
> comments on the mechanism. I have a few minor nits/comments.

> The security
> considerations may benefit from repeating the last sentence of the fourth
> paragraph in the introduction (I.e., not 'meant to be used for
> cryptographic applications’).

[VR] Very good suggestion. Added.

4.  Security Considerations

   The authors do not believe the present specification generates
   specific security risks per se.  However, neither the TinyMT nor MT
   PRNG are meant to be used for cryptographic applications.

> The bibliography should include all of the
> references cited in the draft.

[VR] We agree, and we changed all <eref target=« https://… » />
links to a well identified « Informative References » entry.

              Saito, M. and M. Matsumoto, "Tiny Mersenne Twister
              (TinyMT) github site", <

              Rikitake, K., "TinyMT pre-calculated parameter list github
              site", <>.

              Saito, M. and M. Matsumoto, "Tiny Mersenne Twister
              (TinyMT) web site",

> Adding some text or references to expand on
> the mentioned limitations of RFC5170 or to describe how the parameter set
> from which the parameters selected in this draft would be nice as well. 

[VR] We agree. I’ve added a mention to the « Numerical Recipes in C » 2nd 
edition for the limits of the Park-Miller PRNG specified in RFC 5170, as well
as the companion RLC I-D where we mention the observations we made with
this PRNG.

   […] 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 (see for instance [PTVF92],
   section 7.1, pp. 279, and [RLC-ID], Appendix B).

Concerning the chosen parameter set, they have been selected among an
official list of parameter set values, as explained. It’s a bit arbitrary (we chose
the 1st entry), as explained, but it’s a common parameter set (there’s a 
publication based on it listed in the Informative References section).
There’s of course a theoretical background but I don’t think it’s worth entering 
that kind of details (especially as the two authors didn’t publish a research
paper on TinyMT32).

Thanks a lot for your comments.


  Vincent on behalf of the authors